[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-dev] "clean up" again
|
When I started this thread, I thought this friendly reminder would stand for
itself: a simple request to be a bit more conservative when changing code in
JDT. I should have known better! Very naive of me not to expect the flood of
responses :)
Now that we have invested all this time in discussing the issue, I believe we
owe to ourselves some kind of conclusion to avoid that the debate was nothing
more than a big waste of time.
The JUnit3->4 migration has been separated out as a special case, but what about
the other mass clean-ups?
The position of the senior committers who cared to comment is clear: mass
clean-ups are seen as causing more harm than helping. Looking from a distance
one may suspect this is just a group of stubborn elderly, who don't like anybody
else playing in their backyards, but the problems reported are real: real bugs
have been introduced by what should be 100% safe operations, and working with
the git history - one of our main sources of information - is getting more
cumbersome, despite excellent tooling. Also mass clean-ups do affect adopters.
For completeness it should be stated that a clean-up accidentally caught a
dormant bug, too. OTOH, that bug may not have been relevant in comparison to
those thousands of open bug reports where we know that some user was/is affected
(was a test case ever written demonstrating the effect of that dormant bug?).
Apart from this, the evidence of tangible benefits of the clean-ups is meager,
to put it cautiously. I have not heard any confirmation, that these clean-ups
actually served the purpose of attracting new contributors.
From here I think that it's clear that every change in JDT should start with a
bugzilla entry, and this entry should start with a problem description. If we
don't agree on smth being a problem, then obviously there is no reason for a
change. Without a reason there will be no code change in the master branch.
This explicitly opens up for the case where some code section is beyond repair
by normal means: If a certain code area is incomprehensible or does not allow a
decent fix for a known bug, then this structure can be a problem in itself,
worth cleaning up. OTOH, I think we may take collective pride in the status of
JDT, where such bad code structure is by far the exception rather than the rule.
If just every bug fix strives to leave the code structure in no worse state than
it was before, then JDT can be maintained and evolved for many more years.
Let's pay this respect to those who created this component in exemplary quality
many years ago.
best,
Stephan
On 26.05.20 20:55, Stephan Herrmann wrote:
Hi,
Another episode in the question whether clean up changes are worth the effort
they cause.
Today the Object Teams build got broken by https://git.eclipse.org/r/#/c/155226/
(which doesn't even have a bug that I could re-open).
Object Teams has tons of tests for checking that we don't break JDT. In that
context we have a subclass of org.eclipse.jdt.testplugin.JavaProjectHelper. This
no longer compiles since the above change.
Granted, the package is marked x-internal, so JDT has permission to change any
way we want.
OTOH note that every project that extends JDT is potentially interested in using
also code from the JDT test suite. Here we speak of a fairly large number of
projects.
I would not complain if the change was necessary to implement new functionality
or fix a bug, that's certainly covered by x-internal. But I strongly doubt that
this "clean up" has a benefit that justifies the consequences.
What problem is solved by adding private constructors? Are you doing it just
because it is possible? The commit message doesn't indicate you even thought of
the possibility that s.o. would subclass those classes.
It's too late for changing the code, because I need to fix this today for M3.
But please keep this in mind when doing further clean-up.
Stephan
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
