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

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: 84 MB

• openjdk:11-jre-slim: 283 MB

(Ich betrachte nur das offizielle OpenJDK und die leichtesten Images für jede Java-Version.)

Beim tieferen Graben wurden die folgenden "Dinge" entdeckt:

• Das openjdk:11-jre-slimBild verwendet das Basisbild debian:sid-slim. Dies bringt 2 Probleme mit sich:

  • das ist 60 MB größer als alpine:3.8

  • Die Debian-sid Versionen sind instabil

• Das openjdk-11-jre-headlessim Image installierte Paket ist dreimal 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 modulesDatei des JDK:

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

Nun also die Fragen, die kamen:

• Warum wird es alpinenicht mehr als Basis-Image für schlanke Java 11-Images verwendet?

• Warum wird die instabile Sid- Version für LTS-Java-Images verwendet?

• Warum ist das schlanke / kopflose / JRE-Paket für OpenJDK 11 im Vergleich zum ähnlichen OpenJDK 8-Paket so groß?

  • Was ist diese Moduldatei , 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

Warum wird es alpinenicht mehr als Basis-Image für schlanke Java 11-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 dem Standard-glibc, das von den meisten Linux-Anbietern verwendet wird. Dies bedeutet, dass eine JVM mit musl libc kompatibel sein muss, um Vanilla Alpine zu unterstützen. Der musl OpenJDK-Port wird im Rahmen des OpenJDK- Portola- Projekts entwickelt.

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

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 zu gelten. Bitte verwenden Sie stattdessen den JDK 12 Alpine Linux-Build für den frühen Zugriff.

Die einzigen stabilen OpenJDK-Versionen für Alpine sind derzeit 7 und 8, die vom IcedTea- Projekt bereitgestellt werden .

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

• Es unterstützt Java 11 auf Alpine Musl (Version 11.0.2 zum Zeitpunkt des Schreibens);
• Es handelt sich um einen zertifizierten OpenJDK-Build, der mithilfe der OpenJDK TCK-Konformitätssuite überprüft wurde.
• Es ist kostenlos, Open Source und Docker bereit ( Dockerhub ).

Informationen zur Verfügbarkeit und Roadmap des Supports finden Sie unter Azul-Support-Roadmap .

Update, 06.03.19: Ab gestern openjdk11in alpinen Repositories verfügbar! Es könnte auf Alpine gepackt werden mit:

apk --no-cache add openjdk11

Das Paket basiert auf dem jdk11uOpenJDK-Zweig sowie portierten Fixes aus dem Projekt Portola, die mit der folgenden PR eingeführt wurden . Ein großes Lob und ein großes Dankeschön an das Alpine Team.

Warum wird die instabile Sid- Version für LTS-Java-Images verwendet?

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

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

Warum ist das schlanke / kopflose / JRE-Paket für OpenJDK 11 im Vergleich zum ähnlichen OpenJDK 8-Paket so groß? Was ist diese Moduldatei , die 135 MB in OpenJDK 11 bringt?

Java 9 führte das Modulsystem ein, ein neuer und verbesserter Ansatz zum Gruppieren von Paketen und Ressourcen im Vergleich zu JAR-Dateien. Dieser Artikel von Oracle bietet eine sehr detaillierte Einführung in diese Funktion:
https://www.oracle.com/corporate/features/understanding-java-9-modules.html

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

Zu beachten ist jedoch, dass es ersetzt wird rt.jarund tools.jarunter anderem veraltet ist. Wenn Sie also die Größe von modulesOpenJDK-Builds vor 9 berücksichtigen, sollten die Größen von rt.jarund tools.jarabgezogen werden (sie sollten zusammen etwa 80 MB aufnehmen). .

Stand 07.2019 https://adoptopenjdk.net/ bietet offizielle alpine Unterstützung für Java 11:

• https://github.com/AdoptOpenJDK/openjdk-docker/blob/master/11/jdk/alpine/

• https://hub.docker.com/r/adoptopenjdk/openjdk11

Allerdings Module ( jmods , jlink) noch gelten als wenn man zusammenbaut minimal Anwendung.

Hinweis : Schlanke Bilder enthalten keine Module (wie java.sql) - sie werden explizit ausgeschlossen ( https://github.com/AdoptOpenJDK/openjdk-docker/blob/21b8393b9c23f94d6921a56cce27b026537c6ca2/11/jdk/alpine/slim-java.shL )

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

Im Docker OpenJDK-Repository ist das Bild von Slim JRE 11 kleiner als 70 MB