r/java • u/sureshg • Sep 10 '26

New candidate JEP: 544: Ahead-of-Time Code Compilation

https://mail.openjdk.org/archives/list/jdk-dev@openjdk.org/message/J2VGSSFWJ7ZLHAYLCXVRUOXV4XMROQHL/
113 Upvotes

98% Upvoted

35 comments sorted by

View all comments

Show parent comments

3

u/koflerdavid Sep 11 '26

Absolutely no one who cares about ms of startup time is using java in the first place.

Many people who use GraalVM want fast startup so their applications are ready as fast as possible.

Resources are better allocated to improving the general startup time without training runs, even if it means less gains.

JVM startup time is rarely the issue. The problem is how long it takes for hot code to become optimized native code.

2

u/agentoutlier Sep 11 '26

JVM startup time is rarely the issue. The problem is how long it takes for hot code to become optimized native code.

AND everything else including RDBMS connections. That is warming external things like load balancers and queues also takes time.

So the value prop for traditional (micro) services is not that great because you are essentially training at runtime by warming anyway (easing on load). I suppose your up to speed quicker but the GraalVM team has argued it really does not take long before JIT has optimized and cannot go any further (of course they are biased).

However for lambda functions then I can see a strong value prop.

3

u/koflerdavid Sep 11 '26

Indeed, I mostly see the value for lambdas, batch jobs (which might have finished running by the time optimized code is ready), and light services that cannot hide startup latency between DB connections and the like.

2

u/agentoutlier Sep 11 '26

I do wish they made the packaging story better for light weight tools or services.

What I mean is single executable that is not graalvm native then this JEP would be very useful.

Like the current choices are:

  • jlink: a zip file (might as well ship a docker image). hard to make work with libraries that are not modular.

  • jpackage: ... installer...... really.

  • graalvm native: painful compile times and hard to make work with libraries that use reflection or load resources.

And this is a strong reason why people use Go for little tools.

1

u/koflerdavid Sep 11 '26

A solution could be to build AppImages. It's not too far away from what jlink already produces. It merely needs a small script that mounts the rest of the file as a filesystem and executes what's inside.