Menu
Is AdoptOpenJDK's JRE 11+ the same as just using jlink and adding all dependencies?
Oracle Java 11 onwards doesn't come with JRE only JDK because you can build your own JRE containing only the system modules you need using jlink, and this is what I do on Windows and Linux.
However it is not so obvious to me on how to incorporate a jlinked JRE for some platforms (Docker & MacOS) and since AdoptOpenJDK provides binaries for not just JDK but also JRE I thought I may just use the JRE for these platforms. But does the JRE contain everything I would get if I jlinked the JDK and includes all system module dependencies or not ?
953
In JDK 11, this is no longer an option. In this release, the JRE or Server JRE is no longer offered. Only the JDK is offered. Users can use jlink to create smaller custom runtimes.
But I noticed that Java 11 doesn't have a JRE folder. In Java 9 and Java 10, folder structures are changed i.e. java\jdk1. x or java\jre1.
jlink is a tool that generates a custom Java runtime image that contains only the platform modules that are required for a given application. Such a runtime image acts exactly like the JRE but contains only the modules we picked and the dependencies they need to function.
@PeterLawrey JDK 11 does not include a JRE sub-directory.
Is AdoptOpenJDK's JRE 11+ the same as just using jlink and adding all dependencies? Oracle Java 11 onwards doesn't come with JRE only JDK because you can build your own JRE containing only the system modules you need using jlink, and this is what I do on Windows and Linux.
JDK 9 also eliminated the distinction between the Java Development Kit (JDK) and the Java Runtime Environment (JRE). In the past, there was a sub-directory in the JDK (unsurprisingly called jre) which only contained things that were required to run a Java application.
JDK 9 also eliminated the distinction between the Java Development Kit (JDK) and the Java Runtime Environment (JRE). In the past, there was a sub-directory in the JDK (unsurprisingly called jre) which only contained things that were required to run a Java application. On Linux, the full JDK 8 was 364 Mb, the JRE just 197 Mb.
AdoptOpenJDK uses infrastructure , build und test scripts to produce prebuilt binaries from OpenJDK ™ class libraries and a choice of either OpenJDK or the Eclipse OpenJ9 VM. All AdoptOpenJDK binaries and scripts are open source licensed and available for free. 1. Version auswählen 2. JVM auswählen HotSpot is the VM from the OpenJDK community.
If you download Adopt's JRE and run java --list-modules, you get the following (I removed the version for better readability):
java.base
java.compiler
java.datatransfer
java.desktop
java.instrument
java.logging
java.management
java.management.rmi
java.naming
java.net.http
java.prefs
java.rmi
java.scripting
java.se
java.security.jgss
java.security.sasl
java.smartcardio
java.sql
java.sql.rowset
java.transaction.xa
java.xml
java.xml.crypto
jdk.accessibility
jdk.aot
jdk.charsets
jdk.crypto.cryptoki
jdk.crypto.ec
jdk.dynalink
jdk.httpserver
jdk.internal.ed
jdk.internal.le
jdk.internal.vm.ci
jdk.internal.vm.compiler
jdk.internal.vm.compiler.management
jdk.jdwp.agent
jdk.jfr
jdk.jsobject
jdk.localedata
jdk.management
jdk.management.agent
jdk.management.jfr
jdk.naming.dns
jdk.naming.rmi
jdk.net
jdk.pack
jdk.scripting.nashorn
jdk.scripting.nashorn.shell
jdk.sctp
jdk.security.auth
jdk.security.jgss
jdk.unsupported
jdk.xml.dom
jdk.zipfs
If you download the JDK and use jlink --add-modules java.se to build the image, you get the following:
java.base
java.compiler
java.datatransfer
java.desktop
java.instrument
java.logging
java.management
java.management.rmi
java.naming
java.net.http
java.prefs
java.rmi
java.scripting
java.se
java.security.jgss
java.security.sasl
java.sql
java.sql.rowset
java.transaction.xa
java.xml
java.xml.crypto
As you can see, it contains no jdk.* modules because these are, strictly speaking, not needed for the runtime to work. Still, their absence will be noticed, e.g. without jdk.localedata, only the English locales (or maybe even just US) will work.
If you ask jlink to bind services, you get a different picture, yet sill not the same as the JRE:
java.base
java.compiler
java.datatransfer
java.desktop
java.instrument
java.logging
java.management
java.management.rmi
java.naming
java.net.http
java.prefs
java.rmi
java.scripting
java.se
java.security.jgss
java.security.sasl
java.smartcardio
java.sql
java.sql.rowset
java.transaction.xa
java.xml
java.xml.crypto
jdk.charsets
jdk.compiler
jdk.crypto.cryptoki
jdk.crypto.ec
jdk.dynalink
jdk.internal.opt
jdk.jartool
jdk.javadoc
jdk.jdeps
jdk.jfr
jdk.jlink
jdk.localedata
jdk.management
jdk.management.jfr
jdk.naming.dns
jdk.naming.rmi
jdk.scripting.nashorn
jdk.security.auth
jdk.security.jgss
jdk.unsupported.desktop
jdk.zipfs
The presence of, e.g. jdk.compiler and jdk.javadoc mean that the bin directory will contain the javac and javadoc tools, probably not what you would expect from a JRE.
That tells me that Adopt's JRE is built with a specific module list. If you get hold of that module list or just use the list above to build a runtime image, you should get the exact same behavior as the JRE downloaded from AdoptOpenJDK.
Some caveats: (a) this is just my assumption, so don't bet your project on it, (b) there are plenty of flags you can apply to jlink to fiddle with the resulting image, e.g. compression or strip debug symbols, which will impact its size, performance (slightly), and debugging abilities.
109
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
