For me, jlink (and jpackage) has been useful when sharing an application with someone who may not have proper JDK installed. Otherwise, if I am setting up the environment, it is more efficient to just use the jar/class-files using the already installed JDK.
I think it makes more sense for production deployment where you might need to spin up hundred of microservices and those MB and startup time saved are important.
Also, as you might've noticed, most JDK vendors stopped releasing JRE, only JDK is availalbe (except for Eclipse Temurin). For those with more concern on having JDK stuff in the system is more risky, it makes sense to build custom runtime image.
I have a problem with jpackage because it does not really wrap the jar into an exe but rather the exe file actually just runs the jar file which you can actually manually find inside the installation folder.
Hii, Thank you for creating a more informative video. I have one question regarding Custom JRE. Que: If we create a custom JRE with the help Jdeps and JLink. Can we create that custom JRE folder into docker image and when we create any spring boot project with Docker file, we directly pull that custom JRE from docker, Not pull any openJDK:21 and Not any other image only pull over custom JRE and start our spring boot application, it's possible or not?. Can you please create a video on that. Please 🙏
8:14 I created a custom runtime with the command beblow, but it was 111MB (110MB lib directory only). did I do something wrong? jlink --output custom-java --add-modules java.base OS: Ubuntu 23.10 (x64) java 22 2024-03-19 Java(TM) SE Runtime Environment Oracle GraalVM 22+36.1 (build 22+36-jvmci-b02) Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 22+36.1 (build 22+36-jvmci-b02, mixed mode, sharing)
I like jpackage but I think for the time being I will live with a little bigger disk and memory footprint and not bother spending the time working with jlink😂
As for me, building custom runtimes or native images entails so much overhead which moreover infilters the operation procedures, that it makes using java in greenfield cloud-native environment look more and more unattractive compared to other languages like Golang etc. Yes, the latter one and its libraries have not been as mature nor versatile as those for Java, but easy to write, build, deploy & operate, has a small memory footprint and starts fast.
I only tried it in 1 personal project and it was an absolute pain. If any of your dependencies doesn't support modules, you're doomed. And widely used dependencies like Apache Commons Codec are among these libraries. Never again.
![Quando Rondo - Grow Up [Official Music Video]](http://i.ytimg.com/vi/8zFnCg3BO4Q/mqdefault.jpg)
Java moving ahead with changing times
Cool. We are looking forward to new updates
For me, jlink (and jpackage) has been useful when sharing an application with someone who may not have proper JDK installed. Otherwise, if I am setting up the environment, it is more efficient to just use the jar/class-files using the already installed JDK.
I think it makes more sense for production deployment where you might need to spin up hundred of microservices and those MB and startup time saved are important.
Also, as you might've noticed, most JDK vendors stopped releasing JRE, only JDK is availalbe (except for Eclipse Temurin). For those with more concern on having JDK stuff in the system is more risky, it makes sense to build custom runtime image.
I have a problem with jpackage because it does not really wrap the jar into an exe but rather the exe file actually just runs the jar file which you can actually manually find inside the installation folder.
@@sen7826To create a native executable you can use "native-image" from graalvm JDK. It works well for headless applications.
Once native-image becomes more mature, jlink will be pointless.
Очень информативно, спасибо!
very informative. Thanks!
Great presentation. Thanks
Hii,
Thank you for creating a more informative video.
I have one question regarding Custom JRE.
Que: If we create a custom JRE with the help Jdeps and JLink.
Can we create that custom JRE folder into docker image and when we create any spring boot project with Docker file, we directly pull that custom JRE from docker, Not pull any openJDK:21 and Not any other image only pull over custom JRE and start our spring boot application, it's possible or not?.
Can you please create a video on that. Please 🙏
It would be interesting to see how to handle applications with non-modular third party libraries.
8:14
I created a custom runtime with the command beblow, but it was 111MB (110MB lib directory only). did I do something wrong?
jlink --output custom-java --add-modules java.base
OS: Ubuntu 23.10 (x64)
java 22 2024-03-19
Java(TM) SE Runtime Environment Oracle GraalVM 22+36.1 (build 22+36-jvmci-b02)
Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 22+36.1 (build 22+36-jvmci-b02, mixed mode, sharing)
I like jpackage but I think for the time being I will live with a little bigger disk and memory footprint and not bother spending the time working with jlink😂
As for me, building custom runtimes or native images entails so much overhead which moreover infilters the operation procedures, that it makes using java in greenfield cloud-native environment look more and more unattractive compared to other languages like Golang etc. Yes, the latter one and its libraries have not been as mature nor versatile as those for Java, but easy to write, build, deploy & operate, has a small memory footprint and starts fast.
Maybe stupid question not related to this topic, but is memory leak issue possible in java?
In the JVM, memory management is not manual (like e.g. C++), but done automatically by the JVM's GC (Garbage Collector), so no.
Yes: Running threads are not GC'd, so you must manage them manually.
Nice
This will be huge for lambdas
I only tried it in 1 personal project and it was an absolute pain. If any of your dependencies doesn't support modules, you're doomed. And widely used dependencies like Apache Commons Codec are among these libraries. Never again.
Native images are slowly killing jlink
hello hi