¿Por qué la imagen Docker base de Java 11 es tan grande? (openjdk: 11-jre-slim)

Se anuncia que Java 11 es la versión LTS más reciente. Entonces, estamos tratando de comenzar nuevos servicios basados ​​en esta versión de Java.

Sin embargo, la imagen base de Docker para Java 11 es mucho más grande que el equivalente para Java 8:

• openjdk:8-jre-alpine: 84 MB

• openjdk:11-jre-slim: 283 MB

(Estoy considerando solo el OpenJDK oficial y las imágenes más livianas para cada versión de Java).

Una excavación más profunda descubrió las siguientes "cosas":

• la openjdk:11-jre-slimimagen usa la imagen base debian:sid-slim. Esto trae 2 problemas:

  • esto es 60 MB más grande que alpine:3.8

  • las versiones de Debiansid son inestables

• el openjdk-11-jre-headlesspaquete instalado en la imagen es 3 veces más grande que openjdk8-jre(dentro del contenedor Docker en ejecución):

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

    Profundizando descubrí la "raíz" de esta pesadez: es el modulesarchivo del JDK:

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

Entonces, ahora las preguntas que vinieron:

• ¿Por qué ya alpineno se usa como imagen base para las imágenes delgadas de Java 11?

• ¿Por qué se usa la versión sid inestable para las imágenes Java LTS?

• ¿Por qué el paquete delgado / sin cabeza / JRE para OpenJDK 11 es tan grande en comparación con el paquete OpenJDK 8 similar?

  • ¿Qué es este archivo de módulos que trae 135 MB en OpenJDK 11?

UPD : como solución para estos desafíos, se podría usar esta respuesta: la aplicación Java 11 como imagen acoplable

¿Por qué ya alpineno se usa como imagen base para las imágenes delgadas de Java 11?

Eso es porque, lamentablemente, no hay una versión oficial de OpenJDK 11 estable para Alpine actualmente.

Alpine utiliza musl libc, a diferencia del glibc estándar utilizado por la mayoría de Linux, lo que significa que una JVM debe ser compatible con musl libc para admitir Vanilla Alpine. El puerto musulmán OpenJDK se está desarrollando bajo el proyecto Portola de OpenJDK .

El estado actual se resume en la página OpenJDK 11 :

La versión de Alpine Linux disponible anteriormente en esta página se eliminó a partir de JDK 11 GA. No está listo para la producción porque no se ha probado lo suficiente como para considerarse una compilación de GA. Utilice la compilación JDK 12 Alpine Linux de acceso temprano en su lugar.

Las únicas versiones estables de OpenJDK para Alpine actualmente son 7 y 8, proporcionadas por el proyecto IcedTea .

Sin embargo, si está dispuesto a considerar otro OpenJDK oficial, Zulu OpenJDK de Azul ofrece una alternativa convincente:

• Es compatible con Java 11 en Alpine musl (versión 11.0.2 en el momento de la escritura);
• Es una compilación certificada de OpenJDK, verificada utilizando el paquete de cumplimiento OpenJDK TCK;
• Es gratuito, de código abierto y listo para Docker ( Dockerhub ).

Para conocer la disponibilidad de asistencia y la hoja de ruta, consulte la hoja de ruta de asistencia de Azul .

Actualización, 6/3/19: ¡ A partir de ayer, openjdk11está disponible en repositorios Alpine! Se puede agarrar a Alpine usando:

apk --no-cache add openjdk11

El paquete se basa en la jdk11urama OpenJDK más arreglos portados del proyecto Portola, presentado con el siguiente PR . Felicitaciones y muchas gracias al equipo alpino.

¿Por qué se usa la versión sid inestable para las imágenes Java LTS?

Esa es una pregunta / solicitud justa. En realidad, hay un boleto abierto para proporcionar Java 11 en una versión estable de Debian:
https://github.com/docker-library/openjdk/issues/237

Actualización, 26/12/18: El problema se ha resuelto, y ahora la imagen delgada de OpenJDK 11 se basa en stretch-backportsOpenJDK 11, que recientemente estuvo disponible ( enlace PR ).

¿Por qué el paquete delgado / sin cabeza / JRE para OpenJDK 11 es tan grande en comparación con el paquete OpenJDK 8 similar? Que es esto archivo de módulos que trae 135 MB en OpenJDK 11?

Java 9 introdujo el sistema de módulos, que es un enfoque nuevo y mejorado para agrupar paquetes y recursos, en comparación con los archivos jar. Este artículo de Oracle ofrece una introducción muy detallada a esta característica:
https://www.oracle.com/corporate/features/understanding-java-9-modules.html

El modulesarchivo agrupa todos los módulos enviados con el JRE. La lista completa de módulos se puede imprimir conjava --list-modules . modulesde hecho es un archivo muy grande y, como se comentó, contiene todos los módulos estándar y, por lo tanto, está bastante hinchado.

Sin embargo, una cosa a tener en cuenta es que reemplaza rt.jary se tools.jarconvirtió en obsoleto, entre otras cosas, por lo que, al tener en cuenta el tamaño de modulescuando se compara con las compilaciones de OpenJDK anteriores a 9, los tamaños de rt.jary tools.jardeberían restarse (deberían ocupar unos 80 MB combinados) .

en cuanto a 07.2019 https://adoptopenjdk.net/ tiene soporte oficial de Alpine para Java 11:

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

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

Sin embargo, los módulos ( jmods , jlink) aún se deben considerar cuando se ensambla una aplicación mínima.

Nota : las imágenes delgadas no contienen algunos módulos (como java.sql): se excluyen explícitamente ( 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

en el repositorio docker openjdk, la imagen delgada de jre 11 tiene menos de 70mb