EXPERIMENT: JDT using Javac instead of ECJ

I'd like to share here an ongoing experiment about making JDT use Javac (through API/code) instead of ECJ for some features.
For the moment, the experiment is ongoing on a branch of mine, documentation is available on the branch: https://github.com/mickaelistria/eclipse.jdt.core/blob/parse-with-javac/README_JAVAC_EXPERIMENT.md

For those who just want to get a sense of why we're doing that, let me quote the documentation
"""
This branch is a work in progress experiment to leverage all higher-level JDT IDE features (DOM, IJavaElement, refactorings...) relying on Javac as underlying compiler/parser instead of ECJ.

Why? Some background...
* These days, with more frequent and more features Java releases, it's becoming hard for JDT to **cope with new Java features on time** and **facilitate support for upcoming/preview features before Java is released so JDT can participate to consolidation of the spec**. Over recent releases, JDT has failed at providing the features on time. This is mostly because of the difficulty of maintaining the Eclipse compiler: compilers are difficult bits of code to maintain and it takes a lot of time to implement things well in them. There is no clear sign the situation can improve here.
* The Eclipse compiler has always suffered from occasional **inconsistencies with Javac** which end-users fail at understanding. Sometimes, ECJ is right, sometimes Javac is; but for end-users and for the ecosystem, Javac is the reference implementation and it's behavior is what they perceive as the actual specification
* JDT has a very strong ecosystem (JDT-LS, plugins) a tons of nice features, so it seems profitable to **keep relying higher-level JDT APIs, such as model or DOM** to remain compatible with the ecosystem
"""

For more technical details, please see https://github.com/mickaelistria/eclipse.jdt.core/blob/parse-with-javac/README_JAVAC_EXPERIMENT.md . As you can grok from the document, many features are already working, confirming that Javac-based JDT seems like a viable opportunity.

Concretely, until we see a blocker with this approach, we (Red Hat) will continue focusing on it, with the hope that we can switch JDT-LS to use it; and of course, if/when quality and value are high enough for JDT as well, we would love to also see JDT adopting this strategy by default.
Note that it is *not* a goal to remove ECJ from JDT. The goal is just to enable Javac as an alternative at runtime; it's totally fine that ECJ stays. However, Red Hat will probably stop contributing to ECJ (and focus on both Javac-based JDT and higher-level JDT: DOM, manipulation and so on...)

If you're interested in joining this effort, I'd be glad to assist you in jumping in!