Perché l'immagine Docker di base Java 11 è così grande? (OpenJDK: 11-jre-slim)

Java 11 è stata annunciata come la versione LTS più recente. Quindi, stiamo cercando di avviare nuovi servizi basati su questa versione di Java.

Tuttavia, l'immagine Docker di base per Java 11 è molto più grande dell'equivalente per Java 8:

• openjdk:8-jre-alpine: 84 MB

• openjdk:11-jre-slim: 283 MB

(Sto considerando solo l' OpenJDK ufficiale e le immagini più leggere per ogni versione di Java.)

Scavi più profondi hanno scoperto le seguenti "cose":

• l' openjdk:11-jre-slimimmagine usa l'immagine di base debian:sid-slim. Ciò comporta 2 problemi:

  • questo è 60 MB più grande di alpine:3.8

  • le versioni di Debiansid sono instabili

• il openjdk-11-jre-headlesspacchetto installato nell'immagine è 3 volte più grande di openjdk8-jre(all'interno del contenitore Docker in esecuzione):

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

    Andando più in profondità ho scoperto la "radice" di questa pesantezza - è il modulesfile del JDK:

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

Quindi, ora le domande che sono arrivate:

• Perché alpinenon viene più utilizzato come immagine di base per le immagini snelle di Java 11?

• Perché la versione sid instabile viene utilizzata per le immagini Java LTS?

• Perché il pacchetto slim / headless / JRE per OpenJDK 11 è così grande rispetto al pacchetto OpenJDK 8 simile?

  • Che cos'è questo file di moduli che porta 135 MB in OpenJDK 11?

UPD : come soluzione per queste sfide si potrebbe usare questa risposta: applicazione Java 11 come immagine docker

Perché alpinenon viene più utilizzato come immagine di base per le immagini snelle di Java 11?

Questo perché, purtroppo, non esiste attualmente una build ufficiale OpenJDK 11 stabile per Alpine.

Alpine usa musl libc, al contrario del glibc standard usato dalla maggior parte dei Linux là fuori, il che significa che una JVM deve essere compatibile con musl libc per supportare la vaniglia Alpine. Il port musl OpenJDK è stato sviluppato nell'ambito del progetto Portola di OpenJDK .

Lo stato corrente è riepilogato nella pagina OpenJDK 11 :

La build di Alpine Linux precedentemente disponibile in questa pagina è stata rimossa a partire da JDK 11 GA. Non è pronto per la produzione perché non è stato testato abbastanza accuratamente per essere considerato un build GA. Si prega di utilizzare la build JDK 12 Alpine Linux ad accesso anticipato al suo posto.

Le uniche versioni stabili OpenJDK per Alpine sono attualmente 7 e 8, fornite dal progetto IcedTea .

Tuttavia, se sei disposto a prendere in considerazione qualcosa di diverso dall'OpenJDK ufficiale, lo Zulu OpenJDK di Azul offre un'alternativa convincente:

• Supporta Java 11 su Alpine musl (versione 11.0.2 al momento della stesura);
• È una build certificata OpenJDK, verificata utilizzando la suite di conformità TCK OpenJDK;
• È gratuito, open source e pronto per la finestra mobile ( Dockerhub ).

Per la disponibilità dell'assistenza e la roadmap, consultare la roadmap dell'assistenza Azul .

Aggiornamento, 06/03/19: da ieri openjdk11è disponibile nei repository Alpine! Potrebbe essere afferrato su Alpine usando:

apk --no-cache add openjdk11

Il pacchetto si basa sul jdk11uramo OpenJDK più correzioni portate dal progetto Portola, introdotto con il seguente PR . Complimenti e un enorme grazie alla squadra alpina.

Perché la versione sid instabile viene utilizzata per le immagini Java LTS?

Questa è una domanda / richiesta corretta. In realtà c'è un ticket aperto per fornire Java 11 su una versione Debian stabile:
https://github.com/docker-library/openjdk/issues/237

Aggiornamento, 26/12/18: il problema è stato risolto e ora l'immagine sottile di OpenJDK 11 si basa su stretch-backportsOpenJDK 11 che è stato recentemente reso disponibile ( collegamento PR ).

Perché il pacchetto slim / headless / JRE per OpenJDK 11 è così grande rispetto al pacchetto OpenJDK 8 simile? Che cos'è questo file di moduli che porta 135 MB in OpenJDK 11?

Java 9 ha introdotto il sistema di moduli, che è un approccio nuovo e migliorato per raggruppare pacchetti e risorse, rispetto ai file jar. Questo articolo di Oracle fornisce un'introduzione molto dettagliata a questa funzione:
https://www.oracle.com/corporate/features/understanding-java-9-modules.html

Il modulesfile raggruppa tutti i moduli forniti con JRE. L'elenco completo dei moduli può essere stampato con java --list-modules. modulesè davvero un file molto grande e, come commentato, contiene tutti i moduli standard ed è quindi abbastanza gonfio.

Una cosa da notare, tuttavia, è che sostituisce rt.jare tools.jarche è diventato deprecato, tra le altre cose, quindi quando si considera la dimensione di modulesquando si confronta con build OpenJDK pre-9, le dimensioni di rt.jare tools.jardovrebbero essere sottratte (dovrebbero prendere circa 80 MB combinati) .

come per il 07.2019 https://adoptopenjdk.net/ ha il supporto alpino ufficiale per Java 11:

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

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

Tuttavia, i moduli ( jmods , jlink) devono ancora essere considerati quando si monta un'applicazione minima.

Nota : le immagini slim non contengono alcuni moduli (come java.sql) - sono escluse esplicitamente ( https://github.com/AdoptOpenJDK/openjdk-docker/blob/21b8393b9c23f94d6921a56cce27b026537c6ca2/11/jdk/alpine/slim-java.sh#L33 )

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

nel repository docker openjdk, l'immagine jre 11 slim è inferiore a 70mb