On 11/19/25 18:43, Mickael Istria via
jdt-dev wrote:
[...] That decision to get JDT-LS a subproject of has seemed
right to JDT project leads so far as they approved it initially
(this is required for creation of subproject). Maybe go though
the Creation Review for
eclipse.jdt.ls and surrounding
discussions to read the arguments that made the PLs agree with
that (basically the expected, and confirmed, positive influence
of JDT-LS on the overall situation of JDT).
Let's not speculate but read the original documents. Here's the
only related post I could find on relevant mailing lists:
https://www.eclipse.org/lists/jdt-dev/msg00871.html
Do you have more pointers?
In the linked project proposal it says:
"Why Here?
The Eclipse JDT Language Server implementation is based on
the Eclipse JDT project and projects such as Eclipse Che and
Eclipse Orion are potential users of the server."
IMO, same arguments apply to the JDT-Javac case.
There's a fine difference: back in 2016 jdt-ls was based on stock
JDT.
By contrast, jdt-javac is a competitor of a central part of JDT.
That's not the same relationship.
I disagree on the interpretation of competition:
JDT-LS is a competitor to JDT-UI, meant to replace JDT-UI by other bits of code in competitive IDE. If you consider the state of IDE ecosystem, JDT-LS has actually mostly helped in getting VSCode attract more Java developers, sucking them away for traditional IDEs such as Eclipse. So JDT-LS was challenging the statu quo and was strongly challenging the importance of JDT "as is". Nowadays, most users of JDT are using it via VSCode and JDT-LS. The alternative challenging the statu quo has turned out being the main driver of users and interest towards JDT these days.
What is proposed with JDT-Javac is way less challenging as it is as IDE-independent as JDT itself. But it indeed challenges ECJ by providing an alternative. Isn't it allowed that JDT project can offer alternatives? I don't see anywhere in the JDT project description that the project scope is limited to only supporting 1 underlying compiler. If you can quote any bit of this descriptiont that backs your interpretation that a subproject providing an alternative to ECJ as backend is not welcome according to JDT project goals, I would accept it and retire this idea for now (until JDT project goal is reworked in a way that makes it more open if necessary).
JDT-Javac relies on stock JDT (although as mentioned, the current repo is a fork which is nowadays probably a bad idea, but the only forked bits are in tests). It has already demonstrated for more than a year that it is a viable solution, that Javac can be used in place of ECJ without losing other strong benefits of higher-level JDT. It's not as mature as ECJ-based operations and still suffer from annoying glitches, but it is most often viable, usable and very promising on long term. Just like JDT-LS has demonstrated that an alternative to Eclipse IDE and JDT-UI is viable, relevant and now almost vital to the JDT ecosystem.
Challenging ECJ is not necessarily hurtful for JDT. Offering other possible futures for JDT by accepting alternative to ECJ seem only good.
