Java Containerization Guide: Base Image Selection, JDK/JRE Choice, JVM Options, Signal Handling, Memory Limits, DNS Caching, and Native Compilation

In this article, a senior architect shares a detailed guide on containerizing Java applications, covering everything from base image selection to native compilation.

1. System selection : The three common base images are Alpine, Debian, and CentOS. Alpine offers the smallest size but uses musl libc, which may cause compatibility issues for applications that heavily depend on glibc. For glibc‑dependent workloads, Debian‑based images are recommended.

2. JDK vs JRE : JDK includes development tools such as javac , jps , jstack , jmap and also bundles a JRE. JRE is lighter and sufficient for running a JAR, while JDK is preferred for debugging or when additional tools are needed.

3. JDK selection : Choose Oracle JDK if your code uses private APIs under com.sun.* . Otherwise, OpenJDK distributions (AdoptOpenJDK/Eclipse Adoptium, Amazon Corretto, IBM Semeru, Azul Zulu, Liberica) are suitable. IDE shortcuts: Option + Command + L to format, Control + Option + O to optimize imports.

4. JVM selection : HotSpot is the default and most balanced JVM. OpenJ9 (provided by IBM Semeru) offers faster startup and lower memory usage, making it a good choice for containerized workloads.

5. Signal handling (Graceful shutdown) : When a container stops, the PID 1 process receives a termination signal. If the Java process does not receive this signal, Kubernetes will force‑kill the container, potentially leaving resources unreleased. The article demonstrates several Dockerfile patterns:

FROM eclipse-temurin:11-jdk
COPY entrypoint.bad.sh /
COPY target/app.jar /
CMD ["bash", "/entrypoint.bad.sh"]

This "bad" example fails to forward the signal. A correct approach is to run Java directly:

FROM eclipse-temurin:11-jdk
COPY target/app.jar /
CMD ["java", "-jar", "/app.jar"]

or use an exec wrapper in a script to preserve signal forwarding.

6. Memory limits : Tests with various OpenJDK versions (8u111, 8u131, 8u222, 11.0.15, 11.0.16, 17) show that container‑aware memory tuning became reliable from OpenJDK 11.0.16 onward under Cgroups v2. Flags such as -XX:+UseContainerSupport and -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap are needed for older releases.

7. DNS caching : By default, the JVM caches successful lookups for 30 seconds. Enabling the Security Manager changes the policy to cache forever (‑1). The TTL can be overridden with -Dsun.net.inetaddr.ttl=SECONDS to achieve predictable DNS behavior.

8. Native compilation : GraalVM can compile Java code to a native binary, dramatically reducing startup time. The process requires setting JAVA_HOME and PATH , then running mvn clean package -Dmaven.test.skip=true -Pnative . While native images offer performance gains, they demand code adjustments and are currently more suitable for new projects.

Conclusion : For reliable Java containerization, prefer Debian‑based images when glibc is needed, use JDK for debugging, select HotSpot or OpenJ9 based on performance needs, ensure the entrypoint forwards signals (prefer direct CMD or exec ), configure memory flags appropriate to the JDK version, control DNS TTL explicitly, and consider native compilation with GraalVM for latency‑critical services.