With this standalone compiler, you can rely on all Java 11 javac features to be available, even when using newer Java versions. Specifically, this allows you to:<p>- compile code even if your Java environment isn't a full JDK (Java JRE, for example!)<p>- target Java 1.7 for compilation without any warnings or restrictions.<p>- use the Compiler Tree API without resorting to --add-opens trickery that may eventually fail in newer Java releases<p>- build a modified compiler with additional features or custom tweaks<p>I made this after finding that the otherwise superb "jsweet" Java-to-JavaScript transpiler failed to build and run with Java 16 or newer. Surprisingly, I couldn't find any prior work other than "proper" standalone compilers like Eclipse's ecj that would properly work with modern Java runtimes.<p>I'm excited to see what can be done now that we have this scaffolding.
In the repository, I see<p>> By adding support for GraalVM native image, we could build javac binaries with custom configurations<p>Can you elaborate on what's missing for GraalVM native image support? Is there a particular behavior of javac (e.g. reflection, dynamic class loading, keeping threads alive at compile-time, ...) that is a show stopper for native image compatibility?<p>Overall this project looks cool, and native-image support may allow integration into tools like Babashka to do some crazy things like downloading Java source from somewhere then compiling and loading it into the running image.
This is actually kind of an important concept given how the Java module system now works. There are lots of useful internal bits in the JDK that should really be available to outside use. But because the openjdk project wants to be able to move things around, the internals shouldn't be used directly by applications (shouldn't have ever been used, I guess).<p>So extracting out these bits into separate library code is important. But it also stinks because now there's a fork of this compiler code, which won't necessarily get updates or fixes from openjdk (not without a lot of manual diligence).<p>Anyway, it's definitely a commendable project and I hope that we see more like it.
A neat use case would be to replace Error Prone's use of the compiler tree API. If this gets a Java 21 version soon, I may be able to use it for a new project I was just going to make an Error Prone plugin for.
Very nice, thank you for taking this on! A few questions; the implication here is that ecj does not export the Java compiler api, is that correct? How do j2ee components that require compilation (jsp )handle the “—add-open” requirement?