Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-dev] "clean up" again


I think you are missing the wood for the trees.

The code in question might well have been an API or an internal code withOUT x-internal but could still have broken something at some point.
That's the problem I see with this kind of mass changes: naturally, it's not possible for every piece of refactored code to get the attention
it deserves. And the fact that this has happened before obviously will make people question the purpose.

Also, there's no point in arguing why things in JDT are in certain way. In a code base that is as old, there are bound to be things that are
less than perfect and people simply don't have the time to fix those or fix the repercussions coming from the mass changes.

Lastly, (I know this has been discussed before, but anyway) a gerrit that touches over a hundred files and 18 patch sets and several failures
in the due course must have its own bug.


-----jdt-dev-bounces@xxxxxxxxxxx wrote: -----
To: "Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx>
From: Mickael Istria
Sent by: jdt-dev-bounces@xxxxxxxxxxx
Date: 05/27/2020 04:00AM
Subject: [EXTERNAL] Re: [jdt-dev] "clean up" again


I agree that some test utilities are to be considered as APIs.
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.
It would be worth reviewing ObjectTeams test and identifying some JDT packages to treat as API and remove the x-internal, to prevent from similar errors in the future.

However, I totally disagree that the code cleanup in particular is the issue here; this change is technically and in terms of governance very correct; it just highlighted some other problems in JDT (non-)APIs and/or downstream project synchronization.
I think the real issue is that with more contributors, the JDT project evolves faster than it used to, and as a consequence, can break things faster for downstream projects that relied on unreliable things.

Mickael Istria
Eclipse IDE developer, for Red Hat Developers
jdt-dev mailing list
To unsubscribe from this list, visit

Back to the top