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 ?
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.