I assume that jdt-javac would start as an incubating project?
Yes, I agree it would be best and AFAIK all other people involved in development of jdt-javac would be fine with it.
If so, then much of what I'd like to see discussed can be postponed to the
graduation review (if any). At that point I'd expect that the project
demonstrates two things: (1) quality similar to other JDT components - or better
:) - in terms of feature completeness, correctness, performance
That
part is tricky: quality of Javac itself is better for some parts, worse
for some others. And the correctness is still something that is
actively taking development effort (there are a couple of hundreds
search-related tests that still not passing).
But quality is
definitely an important goal, and is not yet product-level (or jdt-ls
would have enabled it be default already). Still I don't think we need
perfect quality and completeness to bootstrap a project; as long as
there is interest and community.
; and (2) added value.
You mean added value of Javac backend as alternative? Or added-value of making it a dedicated project?
For
the first, the expected benefits are a much easier support for newer
Java features, shift of required skillset from "compiler level" to
"integrator level" (easier to find people capable of contributing),
consistency with Javac (same errors, same messages as what people see on
CI), more opportunities to interact with OpenJDK community, less code
to maintain overall...
The benefits of
making it a clear dedicated projects are the ones I mentioned in my
initial message, namely just clarity the JDT-Javac is independent from
JDT-LS and can serve JDT in other ways; but still remains very strongly
coupled to JDT. This clarity will hopefully help the community to
navigate, organize itself and grow around the various facets of Java
development tools
@Eclipse.