Skip to main content

[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.


On 26.05.20 20:55, Stephan Herrmann wrote:

Another episode in the question whether clean up changes are worth the effort they cause.

Today the Object Teams build got broken by (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.

jdt-dev mailing list
To unsubscribe from this list, visit

Back to the top