Pourquoi l'image Docker de base Java 11 est-elle si grande? (openjdk: 11-jre-slim)

Java 11 est annoncé comme la version la plus récente de LTS. Nous essayons donc de démarrer de nouveaux services basés sur cette version Java.

Cependant, l'image Docker de base pour Java 11 est beaucoup plus grande que l'équivalent pour Java 8:

• openjdk:8-jre-alpine: 84 Mo

• openjdk:11-jre-slim: 283 Mo

(Je ne considère que l' OpenJDK officiel et les images les plus légères pour chaque version de Java.)

Des fouilles plus approfondies ont permis de découvrir les «choses» suivantes:

• l' openjdk:11-jre-slimimage utilise l'image de base debian:sid-slim. Cela amène 2 problèmes:

  • c'est 60 Mo plus grand que alpine:3.8

  • les versions de Debiansid sont instables

• le openjdk-11-jre-headlesspackage installé dans l'image est 3 fois plus volumineux que openjdk8-jre(à l'intérieur du conteneur Docker en cours d'exécution):

  • 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/

    En allant plus loin, j'ai découvert la "racine" de cette lourdeur - c'est le modulesfichier du JDK:

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

Alors, maintenant les questions qui se sont posées:

• Pourquoi n'est-il alpineplus utilisé comme image de base pour les images minces Java 11?

• Pourquoi la version sid instable est-elle utilisée pour les images Java LTS?

• Pourquoi le package slim / headless / JRE pour OpenJDK 11 est-il si volumineux par rapport au package OpenJDK 8 similaire?

  • Quel est ce fichier de modules qui apporte 135 Mo dans OpenJDK 11?

UPD : comme solution à ces défis, on pourrait utiliser cette réponse: application Java 11 comme image docker

Pourquoi n'est-il alpineplus utilisé comme image de base pour les images minces Java 11?

C'est parce que, malheureusement, il n'existe actuellement aucune version stable officielle d'OpenJDK 11 pour Alpine.

Alpine utilise musl libc, par opposition à la glibc standard utilisée par la plupart des Linux, ce qui signifie qu'une JVM doit être compatible avec musl libc pour prendre en charge vanilla Alpine. Le port OpenJDK musl est en cours de développement dans le cadre du projet Portola d'OpenJDK .

L'état actuel est résumé sur le page OpenJDK 11 :

La version Alpine Linux précédemment disponible sur cette page a été supprimée à partir du JDK 11 GA. Il n'est pas prêt pour la production car il n'a pas été suffisamment testé pour être considéré comme une version GA. Veuillez utiliser la version JDK 12 Alpine Linux à accès anticipé à la place.

Les seules versions stables d'OpenJDK pour Alpine sont actuellement 7 et 8, fournies par le projet IcedTea .

Cependant, si vous êtes prêt à envisager autre chose que l'OpenJDK officiel, le Zulu OpenJDK d' Azul offre une alternative convaincante:

• Il prend en charge Java 11 sur Alpine musl (version 11.0.2 au moment de la rédaction);
• Il s'agit d'une version OpenJDK certifiée, vérifiée à l'aide de la suite de conformité OpenJDK TCK;
• Il est gratuit, open source et prêt pour docker ( Dockerhub ).

Pour connaître la disponibilité et la feuille de route du support , consultez Feuille de route du support Azul .

Mise à jour du 06/03/19: à partir d'hier, openjdk11est disponible dans les dépôts Alpine! Il peut être récupéré sur Alpine en utilisant:

apk --no-cache add openjdk11

Le package est basé sur la jdk11ubranche OpenJDK ainsi que sur les correctifs portés du projet Portola, introduits avec le PR suivant . Bravo et merci à l'équipe alpine.

Pourquoi la version sid instable est-elle utilisée pour les images Java LTS?

C'est une question / demande juste. Il existe en fait un ticket ouvert pour fournir Java 11 sur une version Debian stable:
https://github.com/docker-library/openjdk/issues/237

Mise à jour, 26/12/18: Le problème a été résolu, et maintenant l'image mince d'OpenJDK 11 est basée sur stretch-backportsOpenJDK 11 qui a été récemment rendu disponible ( lien PR ).

Pourquoi le package slim / headless / JRE pour OpenJDK 11 est-il si volumineux par rapport au package OpenJDK 8 similaire? Quel est ce fichier de modules qui apporte 135 Mo dans OpenJDK 11?

Java 9 a introduit le système de modules, qui est une approche nouvelle et améliorée pour regrouper les packages et les ressources, par rapport aux fichiers jar. Cet article d'Oracle donne une introduction très détaillée à cette fonctionnalité:
https://www.oracle.com/corporate/features/understanding-java-9-modules.html

Le modulesfichier regroupe tous les modules fournis avec le JRE. La liste complète des modules peut être imprimée avec java --list-modules. modulesest en effet un très gros fichier, et comme commenté, il contient tous les modules standard, et il est donc assez gonflé.

Une chose à noter cependant est qu'il remplace rt.jaret tools.jarqui est devenu obsolète, entre autres choses, donc lorsque l' on tient compte de la taille de modulespar rapport aux versions OpenJDK antérieures à 9, les tailles de rt.jaret tools.jardevraient être soustraites (elles devraient prendre environ 80 Mo combinés) .

comme pour 07.2019 https://adoptopenjdk.net/ a un support Alpine officiel pour Java 11:

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

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

Cependant, les modules ( jmods , jlink) doivent toujours être considérés quand on assemble une application minimale.

Remarque : les images minces ne contiennent pas certains modules (comme java.sql) - ils sont exclus explicitement ( https://github.com/AdoptOpenJDK/openjdk-docker/blob/21b8393b9c23f94d6921a56cce27b026537c6ca2/11/jdk/alpine/slim-java.sh#L233 )

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

dans le référentiel docker openjdk, l'image slim jre 11 est inférieure à 70 Mo