Keywords: Java 11 | Docker Images | Module System | Alpine Linux | Container Optimization
Abstract: This paper comprehensively examines the technical reasons behind the significant size increase of official Java 11 Docker images compared to Java 8 versions. Through detailed comparison of openjdk:8-jre-alpine and openjdk:11-jre-slim, we analyze key factors including base image selection, modular system implementation, and Alpine compatibility issues. The article provides alternative solutions using Azul Zulu and Alpine repositories, while explaining the impact of Java's module system on container image sizes.
Overview of Java 11 Docker Image Size Issues
With Java 11 becoming the latest Long-Term Support version, developers have encountered a significant challenge: the official OpenJDK 11 lightweight Docker image reaches 283MB, while its Java 8 counterpart remains at only 84MB. This 3.4x size difference stems from three primary technical changes in the container ecosystem.
Technical Differences in Base Image Selection
Java 8's lightweight image utilizes Alpine Linux as its base system - a minimalist Linux distribution specifically designed for container environments. However, for Java 11, the official image shifted to Debian sid-slim as the base image, resulting in two immediate impacts:
- The Debian sid-slim image itself is approximately 60MB larger than Alpine 3.8
- The sid version belongs to Debian's unstable branch, making it unsuitable for production environments
This change fundamentally originates from Alpine Linux's use of musl libc instead of the standard glibc. OpenJDK's Portola project is developing musl-compatible versions, but it hadn't reached production readiness during Java 11's release. The OpenJDK official page explicitly states: "The Alpine Linux build was removed as of JDK 11 GA. It's not production-ready because it hasn't been tested thoroughly enough to be considered a GA build."
Modular System Implementation and Size Impact
The module system introduced in Java 9 represents a key technical factor contributing to JRE package size increase. Comparing the JRE library directories of both versions:
# Java 8
/usr/lib/jvm/java-1.8-openjdk/jre/lib/ - 57.5MB
# Java 11
/usr/lib/jvm/java-11-openjdk-amd64/lib/ - 179MB
Further analysis reveals that the modules file in Java 11 alone occupies 135MB of space. This file contains all standard modules of the Java platform, replacing the rt.jar and tools.jar files from Java 8. While the modules file is substantial in size, it's important to recognize that it consolidates functionality previously distributed across multiple jar files.
Technical Solutions and Alternative Approaches
To address the Alpine compatibility gap, developers can consider the following alternatives:
- Azul Zulu OpenJDK: Provides TCK-certified Java 11 Alpine versions with musl libc support
- Alpine Official Repository: Since March 2019, Alpine repositories offer openjdk11 packages based on the jdk11u branch
Regarding base image stability, Docker official images have migrated Java 11 slim from Debian sid to stretch-backports, ensuring better stability for production use.
Deep Understanding of the Module System
Java's module system allows viewing all available modules through the java --list-modules command. Although the modules file is large in size, it provides enhanced encapsulation, reliability, and security. Developers can utilize the jlink tool to create customized runtime images containing only the modules required by their applications, significantly reducing final deployment image sizes.
Practical Recommendations and Best Practices
For production environments, we recommend adopting the following strategies:
- Evaluate the feasibility of using Azul Zulu or Alpine official openjdk11 packages
- Leverage jlink tools to create minimal Java runtime environments
- Regularly monitor Docker official image updates, particularly stability improvements in base images
- Incorporate image size monitoring into CI/CD pipelines to ensure deployment efficiency
Through these technical approaches, developers can enjoy Java 11's new features while effectively controlling container image sizes, achieving an optimal balance between performance and efficiency.