[GR-65445] AOT-compile javac and ship it with the jdk distribution

[vlsi]

Feature request

It would be great to make javac faster, and it looks like GraalVM could improve it.

The idea is that JDK image could include the compiled binaries for javac, so the users do not spend time on JIT-compiling javac.

Describe the solution you'd like.

Build native images for javac, and include them into jdk image.

It might be that -processor would require classloading, so javac should be modified to fallback to the current Java-based implementation.

I believe it could be completely transparent for the end-users.

Describe who do you think will benefit the most.

Java developers.

Describe alternatives you've considered.

One could consider building native-images on their own, however, the users would have to build images for every jdk distribution.

Express whether you'd like to help contributing this feature

I might be interested in contributing (code, benchmarks)

[sgammon]

Hey @vlsi,

We just added this in Elide at our latest release, beta3. We embed kotlinc too. I'd love to follow this issue because we haven't addressed processors/classloading just yet. Although javac is built in native mode, we also embed support for Espresso, so I was thinking maybe we could use that to bridge, or alternatively the JNI invocation API.

Javac is embedded as-is, and accepts identical command line flags. We also ship a Maven installer for good measure; dependencies can be added via Apple's Pkl dialect and soon via pom.xml.

If you find this interesting, we can work on making it stable in the ways that are important to you. Let me know!

Our latest release where javac is supported: https://github.com/elide-dev/elide/releases/tag/1.0.0-beta3

Javac is usable as:

javac ...
elide javac -- ...

Run elide javac -help for help. Local JDK required; JDK up to 24 supported (in theory).

Initial findings show this is about 20x faster than stock javac for projects that tend toward smaller class compilation cycles. @simonis wrote some benchmarks (here) which show performance converging for JIT around 10k classes, so perhaps native-imaged javac is an optimal route for projects that don't meet that threshold, or don't meet it regularly.

[sgammon]

(I should also say that promoting such a javac to the JDK is also a great idea, outside of the support we can offer ahead of that.) +1

[selhagani]

Hi @vlsi,

Thank you for reaching out to us about this. I shared your suggestion with our team and I'll make sure to keep you updated in the future about it.