Java 11 and Docker

I know i was a little light on the JAVA 11 parts of the last series of posts. So i have written a separate blog post on Java 11 and Docker and 1 issue that could be a problem.

The innovations in Java 11 are relatively clear. This is not surprising due to the short period since the previous version was published. 

What has been removed and added to Java 11?

The announcements in the form of deprecations in versions 9 and 10 have now become a reality in Java 11. In JEP 320, various Java Enterprise Packages were removed from Java SE, including JAX-WS (XML-based SOAP web services including the tools wsgen and wsimport ), JAXB (Java XML binding including the tools schemagen and xjc ), JAF (Java Beans Activation Framework), Common Annotations ( @PostConstruct, @Resource, ...), CORBA and JTA (Java Transaction API).

Another new feature is that the Oracle JDK will no longer contain JavaFX (by the way, it has never been delivered with the OpenJDK). Instead, JavaFX is offered as a separate download via OpenJFX and can be used in any Java application like any other library. Moreover, in JavaFX, support for applets and Java Web Start will also be stopped. But, the open-source community is already thinking follow-up projects. If you still want to use Java Web Start at the moment, you must first stay with the Oracle JDK 8 and either live without security updates or spend money on commercial support from 2019.

The JavaScript engine rhino was newly marked as deprecated in Java 11 . It can be assumed that it will disappear in future versions of Java. Rhinoceros, however, never really prevailed over Node.js as a server-side JavaScript implementation. And with the GraalVM, Oracle is now taking alternative ways to run other programming languages natively on the JVM.

Incidentally, as of Java 11, the Java runtime environment (JRE) will only be available in the server variant and no longer for desktops. However, you can now easily create size-adjusted runtime environments for desktop applications using the module system and the jlink tool.

Java 11's basic docker image size (OpenJDK's: 11th JRE-thin environment)

Java 11 announced the latest LTS version. So, we're trying to launch new services based on this version of Java.

However, the choice of image customization for Java 11 far exceeds the equivalent for Java 8:

• openjdk:8-jre-alpine: 84 MB
• openjdk:11-jre-slim: 283 MB

(I'm only considering official OpenJDK packages and the lightest images for each version of Java.)

Deeper digging revealed the following on “things” by:

• Now the openjdk:11-jre-slim image uses the base image debian:sid-slim This brings 2 problems:
• it's 60 MB more than alpine:3.8
• in Debian sid versions are unstable
• in packages OpenJDK-11-environment JRE-headless package installed in the image ** 3 times more ** than openjdk8 JRE` environment (works inside the Docker container)

Going deeper the “root” of this severity is the modules JDK file:

Generic-SUG in / usr / lib in / in jvm / java-in 11-packages OpenJDK-amd64 in the / lib / modules directory

135m / usr / lib / in jvm / java c-11-use OpenJDK-amd64 on modules in / lib /

So, now the Problems arrived are:

• Why is Alpinen't thin images used as the base image for Java 11?
• Why is this unstable version of sid used for LTS Java images?
• Why is the thin / headless / JRE and OpenJDK 11 package so large compared to the similar OpenJDK package in 8?
• What is this modules file that brings 135 MB to OpenJDK in 11?

Solution to these problems:

We need a better way to optimize the Java 11 applications to be used or delivered as docker images. For this, consider that the application jar is located at build/libs/spring-boot-demo.jar before the Docker build.

Jedi path:

1. We will use a more stable image as a base image that is, debian:stretch-slim
2. And a Docker multi stage build. It has two build stages.

Docker Build Stage Number 1

1. On the first Docker build stage, you have to download and install an archive named Oracle OpenJDK
2. And then compile aka JRE (Java minimal distribution) using jlink tool

Docker Build Stage Number 2

1. Copy aka JRE (Java minimal distribution) from Docker Build Stage Number 1 to a new image and to access the Java configure the path. Lastly, you have to copy the application jar to this image.

The final look of docker file will be like (actualize JDK VERSION, URL and HASH value) and the result will be a minimal, small and more stable modules image size.