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.