[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-dev] "clean up" again
|
> Am 27.05.2020 um 00:29 schrieb Mickael Istria <mistria@xxxxxxxxxx>:
> But if some classes in tests are famous for being used as APIs in downstream projects, why have they been marked as internal for so many years at the risk of seeing such non-backward compatible change happen at some time?
> IMO, if some project clearly needs this code as API, then the code should be API and not "x-internal". We have strong capabilities to prevent API breakage, and they can be leveraged easily both in IDE and a buid-time; so there is no technical issue here.
That may be true. I even created a few tickets for such code:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=527754
https://bugs.eclipse.org/bugs/show_bug.cgi?id=527756
But it is a lot of work and nobody works on them (and I don’t want to either, as all contributions are in my spare time), so I stopped creating tickets like this after the auto-closing startet.
Also note the number of "x-friends“-declaration in the MANIFEST.MF-File of Platform and JDT. Almost all of them point to code that should probably be API.
My take on "cleanups“:
The conversion to enhanced „for“-loops was the only one that in my eyes is actually is purely a improvement, often they are just style changes.
- A lambda is at least almost always better than an anonymous class, but also not always
- A method reference is not always better than a lambda
- A switch is not always better than a if-cascade
- A pushed down negation is not always easiertto read
...
So I think that most of these „cleanups“ should be done on when somebody works on the code and can make the proper decisions and not by running some automated tool.
And even then, there should be a bug for all substantial changes (not trivial stuff like doc fixes):
First of all, it is easier to discuss and reference later.
But almost as important, at least I only watch activity in bugzilla, so I only see these changes without bugs AFTER they are commited, so they are always a surprise, and then, hard to discuss afterwards.
And no, I think it is not reasonable to expect that gerrit is monitored additionally.
(BTW: There are some very valuable „cleanups" that would be a great improvement:
- add type parameters to raw types
- add null type annotations.
Of this would be a lot of work, so nobody works on this.)
