Java's Custom Runtime Builder - jlink
Вставка
- Опубліковано 8 чер 2024
- jlink is a powerful command line tool for building custom Java runtimes. In this episode of Stack Walker, we look at the history behind the development of jlink and how it can be used to build a runtime optimized for your application.
-- Chapters --
0:00 Intro
3:00 Java Modules
5:27 Link Time
6:43 jlink
7:41 Why use jlink?
10:23 jdeps
12:03 Multi-release jars
13:27 jlink Plugins
15:50 package
16:19 Future
16:45 Conclusions
-- Resources --
JEP 200 ➱ openjdk.org/jeps/200
JEP 261 ➱ openjdk.org/jeps/261
JEP 282 ➱ openjdk.org/jeps/282
The jlink Command ➱ docs.oracle.com/en/java/javas...
jlink tutorial ➱ dev.java/learn/jvm/tools/core...
Dev.java ➱ dev.java
Inside.java ➱ inside.java
Tags: #Java #Cloud #OpenJDK #JDK #JVM #InsideJava - Наука та технологія
Cool. We are looking forward to new updates
Java moving ahead with changing times
very informative. Thanks!
Great presentation. Thanks
Очень информативно, спасибо!
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.
Nice
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😂
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.
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.
This will be huge for lambdas
hello hi
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