jre and jre-with-tools

[dkirrane]

Have you mcr.microsoft.com/openjdk/... tags equivalent to the Azure Zulu image tags for JRE and JRE with Tools?

• mcr.microsoft.com/java/jre-headless:11u11-zulu-alpine
• mcr.microsoft.com/java/jre-headless:11u11-zulu-alpine-with-tools

[karianna]

For Alpine not (yet). We're still gathering customer feedback on whether we will have a supported Alpine image going forward.

In the meantime you can follow our workaround documented in https://docs.microsoft.com/en-us/java/openjdk/containers

[dkirrane]

Thanks, for jlink command would the below modules be what's needed for the 'traditional' jre distro?

Is there any recommendation for AKS?
I think it's typical to have images for 2 cases:

• with tools for cases where developers can kubectl exec into container and run jmap, jstack?
• without tools for minimal jre image where user cannot even kubectl exec into container?

RUN $JAVA_HOME/bin/jlink \
         --add-modules 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.attach,jdk.charsets,jdk.crypto.cryptoki,jdk.crypto.ec, \
                       jdk.dynalink,jdk.httpserver,jdk.internal.ed,jdk.internal.jvmstat,jdk.internal.le,jdk.internal.vm.ci,jdk.internal.vm.compiler, \
                       jdk.internal.vm.compiler.management,jdk.jcmd,jdk.jdwp.agent,jdk.jfr,jdk.jsobject,jdk.localedata,jdk.management,jdk.management.agent, \
                       jdk.management.jfr,jdk.naming.dns,jdk.naming.ldap,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,org.openjsse
         --strip-debug \
         --no-man-pages \
         --no-header-files \
         --compress=2 \
         --output /javaruntime

[karianna]

That list is indeed what you would have to make a runtime that behaved like the JRE of old. You may wish to experiment with things like removing java.desktop from that if you're running a server-side application only (such as what most folks run in AKS).

Yes, you could choose to provide a runtime + some tools for a more debug-friendly use case and have a very locked down runtime for those ultra-secure deployments! :-)

@brunoborges Should we open an issue to cover what we see as the 2-3 most common sets of modules?

[brunoborges]

@dkirrane if you are in a Linux environment (or macOS), you can do something like this:

jlink --add-modules $(java --list-modules) \
         --strip-debug \
         --no-man-pages \
         --no-header-files \
         --compress=2 \
         --output /javaruntime

This will create a Java runtime that has all the modules available in the JDK you are building the runtime from. With some bash magic, you may be able to do an exclusionary set up (as in, add all modules except module A, B, and C).

For packages such as jre-headless-with-tools, the benefit in storage size is not significant to justify building and maintaining them compared to just using the JDK. For other jre* packages, the use of jlink is recommended. We published documentation on this: https://docs.microsoft.com/en-us/java/openjdk/java-jlink-runtimes

Regarding Alpine, it is as @karianna said: we are still evaluating.

[mattwelke]

Found this while learning about jlink. Just wanted to say that at first I was nervous about not seeing a JRE image available and reading in the docs that the new approach is to build your own JRE using jlink. But the example in the docs was great. I was able to adapt the Dockerfile to my own use case (changing Java 11 to Java 16 and changing the COPY at the bottom so that my JAR was copied in) and ended up with a nice small image that was 46 MB compressed. I like this new approach of requiring users to build their own JREs but giving them ample documentation to help them do so.

[brunoborges]

Found this while learning about jlink. Just wanted to say that at first I was nervous about not seeing a JRE image available and reading in the docs that the new approach is to build your own JRE using jlink. But the example in the docs was great. I was able to adapt the Dockerfile to my own use case (changing Java 11 to Java 16 and changing the COPY at the bottom so that my JAR was copied in) and ended up with a nice small image that was 46 MB compressed. I like this new approach of requiring users to build their own JREs but giving them ample documentation to help them do so.

Thank you so much for the feedback!