Reputation: 3168
We are studying how to upgrade to Java 9. A new feature is JLINK is to generate our own JRE, that perfectly matches our application.
I have some naive questions about it:
in which case should we do it? I understand the benefit for a micro-service, but what about a web application?
are big companies really using it, or do they use mostly usual JDKs?
how to maintain a JLINK JRE? Should we rebuild it at each new Java release (and so for Docker images...)
if graalVM is compatible with our application, isn't it always better/easier?
Thanks.
Upvotes: 5
Views: 1319
Reputation: 13700
jlink
is meant to make Java applications be easily shippable to other machines without the expectation of it having a JVM installed.
Instead of shipping jars and running them with a local java
command (which may not match the Java version the program was compiled against), you ship your application as a self-contained image which includes not only your code, but the JVM's code as well (but only the parts required to run the application).
A typical, not so big jlink application, after compacted, will be only around 50MB (again, this is including the JVM).
Now, to your questions:
in which case should we do it?
In cases where you don't want to have the trouble of counting on a compatible JVM being pre-installed where the application will be executed, and you don't benefit much from shipping the smallest possible application (which would be only the set of jars your app consists of).
are big companies really using it, or do they use mostly usual JDKs?
I cannot answer this with certainty, but as jlink is a relatively new tool, I don't expect a lot of big companies to be already using it.
This will change with time, as jlink can help a lot, as you mention, making Java microservices, which are very popular, easier to deploy.
how to maintain a JLINK JRE? Should we rebuild it at each new Java release (and so for Docker images...)
You just choose which JDK to use to compile your application, and jlink
(which is part of the JDK) will build it for you. To upgrade the JVM you ship, you just upgrade the JDK you use to build.
I would recommend upgrading it often as the JDK ships with lots of security fixes, usually, every quarter.
if graalVM is compatible with our application, isn't it always better/easier?
The choice of using GraalVM or other JDK distributions seems orthogonal to using jlink, unless you mean building native images with GraalVM instead of jlink images?? In which case, I would say jlink is more solid at this stage: everything will pretty much work as expected if you use jlink to build your application, while GraalVM's native-image is still pretty experimental, many common Java applications will not work on native images from the little experimentation I've done so far, without quite substantial effort... if your application works with native-image, it does indeed have some benefits, like a smaller footprint both in terms of image size and RAM consumption, and much faster start up... but it may have lower peak performance after the JVM is warm as it cannot perform JIT as a full JVM does.
Upvotes: 5