Warum ist das Basis-Docker-Image von Java 11 so groß? (openjdk:11-jre-slim)

Question 1

Java 11 wird als neueste LTS-Version angekündigt. Wir versuchen also, neue Dienste basierend auf dieser Java-Version zu starten.

Das Basis-Docker-Image für Java 11 ist jedoch viel größer als das Äquivalent für Java 8:

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

(Ich denke nur an die offizielles OpenJDK und das leichteste Bilder für jede Java-Version.)

Beim tieferen Graben wurden folgende “Dinge” entdeckt:

das openjdk:11-jre-slim image verwendet das Basis-Image debian:sid-slim. Dies bringt 2 Probleme mit sich:
- das ist 60 MB größer als alpine:3.8
- das Debian sid Versionen sind instabil

das openjdk-11-jre-headless Paket im Image installiert ist 3 mal größer als openjdk8-jre (innerhalb des laufenden Docker-Containers):

openjdk:8-jre-alpine:

/ # du -hs /usr/lib/jvm/java-1.8-openjdk/jre/lib/
57.5M   /usr/lib/jvm/java-1.8-openjdk/jre/lib/

openjdk:11-jre-slim:

# du -sh /usr/lib/jvm/java-11-openjdk-amd64/lib/
179M    /usr/lib/jvm/java-11-openjdk-amd64/lib/

Als ich tiefer ging, entdeckte ich die “Wurzel” dieser Schwere – es ist die modules Datei des JDK:

# ls -lhG /usr/lib/jvm/java-11-openjdk-amd64/lib/modules
135M    /usr/lib/jvm/java-11-openjdk-amd64/lib/modules

So, jetzt die Fragen, die gekommen sind:

Warum ist alpine nicht mehr als Basis-Image für Java 11 Slim-Images verwendet?
Warum ist das instabil sid Version, die für LTS-Java-Images verwendet wird?

Warum ist das Slim/Headless/JRE-Paket für OpenJDK 11 so groß im Vergleich zum ähnlichen OpenJDK 8-Paket?
- Was ist das Module Datei, die 135 MB in OpenJDK 11 bringt?

UPD: Als Lösung für diese Herausforderungen könnte man diese Antwort verwenden: Java 11-Anwendung als Docker-Image

Question 2

Warum ist alpine nicht mehr als Basis-Image für Java 11 Slim-Images verwendet?

Das liegt daran, dass es derzeit leider keinen offiziellen stabilen OpenJDK 11-Build für Alpine gibt.

Alpine verwendet musl libc, im Gegensatz zu der Standard-glibc, die von den meisten Linuxen verwendet wird, was bedeutet, dass eine JVM mit musl libc kompatibel sein muss, um Vanilla Alpine zu unterstützen. Der Musl OpenJDK-Port wird unter OpenJDK entwickelt Portola Projekt.

Der aktuelle Stand ist auf der zusammengefasst OpenJDK 11-Seite:

Der zuvor auf dieser Seite verfügbare Alpine Linux-Build wurde ab JDK 11 GA entfernt. Es ist nicht produktionsbereit, da es nicht gründlich genug getestet wurde, um als GA-Build betrachtet zu werden. Bitte verwenden Sie stattdessen den Early-Access-JDK 12 Alpine Linux-Build.

Die einzigen stabilen OpenJDK-Versionen für Alpine sind derzeit 7 und 8, bereitgestellt von der Eistee Projekt.

Wenn Sie jedoch bereit sind, andere als das offizielle OpenJDK in Betracht zu ziehen, Azuls Zulu OpenJDK bietet eine überzeugende Alternative:

Es unterstützt Java 11 auf Alpenmusel (Version 11.0.2 zum Zeitpunkt des Schreibens);
Es ist ein zertifizierter OpenJDK-Build, der mit der OpenJDK TCK-Compliance-Suite verifiziert wurde;

Es ist kostenlos, Open Source und Docker-fähig (Dockerhub).

Informationen zur Supportverfügbarkeit und Roadmap finden Sie unter Azul-Support-Roadmap.

Aktualisierung, 06.03.19: Seit gestern, openjdk11 ist in Alpine Repositories verfügbar! Es kann auf Alpine abgerufen werden mit:

apk --no-cache add openjdk11

Das Paket basiert auf der jdk11u OpenJDK-Zweig plus portierte Korrekturen aus dem Projekt Portola, eingeführt mit dem Folgenden PR. Kudos und riesen Dank an das Alpine Team.

Warum ist das instabil sid Version, die für LTS-Java-Images verwendet wird?

Das ist eine berechtigte Frage/Anfrage. Es gibt tatsächlich ein offenes Ticket für die Bereitstellung von Java 11 auf einer stabilen Debian-Version:
https://github.com/docker-library/openjdk/issues/237

Update vom 26.12.18: Das Problem wurde behoben, und jetzt basiert das OpenJDK 11 Slim-Image auf stretch-backports OpenJDK 11, das kürzlich verfügbar gemacht wurde (PR-Link).

Warum ist das Slim/Headless/JRE-Paket für OpenJDK 11 so groß im Vergleich zum ähnlichen OpenJDK 8-Paket? Was ist das Module Datei, die 135 MB in OpenJDK 11 bringt?

Mit Java 9 wurde das Modulsystem eingeführt, das im Vergleich zu JAR-Dateien einen neuen und verbesserten Ansatz zum Gruppieren von Paketen und Ressourcen darstellt. Dieser Artikel von Oracle gibt eine sehr detaillierte Einführung in diese Funktion:
https://www.oracle.com/corporate/features/understanding-java-9-modules.html

Das modules -Datei bündelt alle Module, die mit der JRE geliefert werden. Die komplette Modulliste kann mit ausgedruckt werden java --list-modules. modules ist in der Tat eine sehr große Datei, und wie kommentiert, enthält sie alle Standardmodule und ist daher ziemlich aufgebläht.

Eine Sache zu beachten ist jedoch, dass es ersetzt rt.jar und tools.jar was unter anderem bei der Berücksichtigung der Größe veraltet wurde modules Beim Vergleich mit Pre-9 OpenJDK-Builds sind die Größen von rt.jar und tools.jar abgezogen werden (sie sollten zusammen etwa 80 MB belegen).

Question 3

Wenn Sie nur offizielle Bilder in Betracht ziehen und Ihr Ziel darin besteht, das kleinere verfügbare JRE-Bild zu verwenden, würde ich Ihnen vorschlagen, sich das anzuschauen offizielles OpenJDK Bild openjdk:11-jre-slim-buster das sind nur 69,2 MB.

Question 4

Stand 07.2019 https://adoptopenjdk.net/ hat offizielle Alpine-Unterstützung für Java 11:

Allerdings sind Module (jmods, jlink) noch berücksichtigt werden, wenn man minimale Anwendung zusammenstellt.

Notiz: schlank Bilder enthalten einige Module nicht (wie z java.sql) – sie werden ausdrücklich ausgeschlossen (https://github.com/AdoptOpenJDK/openjdk-docker/blob/21b8393b9c23f94d6921a56cce27b026537c6ca2/11/jdk/alpine/slim-java.sh#L233)

Question 5

https://hub.docker.com/_/openjdk?tab=tags&page=1&name=11.0.7-jre-slim

im docker openjdk-repository ist das slim jre 11-image kleiner als 70 mb