Eclipse Temurin vs Other Java Base Images in 2026

Eclipse Temurin is Adoptium's build of OpenJDK, and it is the default answer for most containerised Java workloads because it is free, TCK-tested and vendor-neutral. The real decision is not which OpenJDK build you take but which layer you put it on and how often that layer gets rebuilt. A JDK image is roughly three times the size of a JRE image and carries a compiler you do not need at runtime - and the distribution underneath both is where almost all of your CVEs will come from.

What is Temurin, and why is it the common default?

Temurin is produced by Adoptium, an Eclipse Foundation project, from "a fully open source set of build scripts and infrastructure." Two properties explain its adoption:

• It is a compatible implementation, not a fork. Adoptium states that "each Temurin release has passed the relevant Oracle Java Compatibility Kit (JCK) to demonstrate that it is a compatible implementation of the Java specification."
• It is quality-gated beyond the JCK. Releases must also "pass the AQAvit quality verification suite to ensure they are ready for production usage," covering performance, security, resilience and application compatibility.

Licensing is GPLv2 with the Classpath Exception, and Adoptium provides the binaries "at no cost to you… to use, forever." That combination - no field-of-use restrictions, no per-core licence conversation, no fork risk - is why it displaced Oracle JDK in most container pipelines.

None of that says anything about the container image. The JCK certifies the Java runtime. It does not certify the Debian or Alpine layer the runtime is shipped on, and that layer is what your scanner reports.

Where do Java container CVEs actually come from?

Not from the JVM. Echo's container study - daily scans over twelve months, more than 10 million individual vulnerability observations across roughly 40,000 CVE journeys - found that 56% of container CVEs come from software not needed in production: unused OS utilities, optional dependencies, kernel headers and developer tooling left in the final image.

A standard eclipse-temurin:21-jdk image is a full Ubuntu userland plus a complete JDK. You are shipping javac, jshell, jlink, the full set of diagnostic tools, apt, a shell, and a general-purpose distribution - to run a Spring Boot fat jar that needs none of them. The growth rate is the part teams underestimate: across Echo's tracked artifacts, open-source CVE counts rose from roughly 150,000 in January 2026 to more than 1.3 million by mid-year, while Echo-maintained versions stayed comparatively flat.

How the Java base image options compare

Sources: Adoptium FAQ; Echo, Mythos Readiness Report; Echo, Mythos readiness.

The Alpine row deserves a flag. Alpine uses musl rather than glibc, which is generally less disruptive for Java than for Python or Node because the JVM abstracts most libc calls - but it still bites anything using JNI, native agents, or profilers built against glibc. Test rather than assume.

Three decisions that matter more than the JDK vendor

1. JRE over JDK in the runtime stage. Build with the JDK, run on the JRE. Nothing that ships a compiler to production is a security posture. If you are on Java 9 or later, jlink goes further: it produces a runtime containing only the modules your application declares, which removes both size and attack surface at once.

2. Multi-stage builds, not smaller tags. The single largest reduction comes from separating the build environment from the runtime environment, not from picking a leaner tag. Our write-up on building slim containers covers where the trade stops paying off.

3. Know whether your binaries are static or dynamic. Java complicates the usual assumptions - GraalVM native images behave very differently from a JVM-on-glibc deployment, and that changes which base image is even viable. Static vs. dynamic binaries walks through the consequences.

What a maintained Java base image should commit to

Adoptium publishes builds on a release cadence. It does not promise to rebuild your image the day a libxml2 advisory lands, and it is not obliged to backport anything. That gap is the one worth closing deliberately:

• A published remediation clock. Echo states that "vulnerabilities are handled within 24 hours and fixed in up to 7 days."
• Backports to the version you already run. Echo "backports fixes to the versions you already run, helping you remediate vulnerabilities without disruptive migrations or application changes" - which for Java, where LTS pinning is near-universal, matters more than it does elsewhere.
• Coordinated disclosure rather than waiting on NVD. As an authorised CNA, Echo "protects customers during the embargo period, coordinates responsible disclosure with maintainers, and converges back upstream once the official fix ships."
• A signed SBOM, not a package manifest you reconstruct at audit time.

For context on how much of this you can reasonably expect from free upstream images versus a commercial commitment, open source vs. commercial hardened container images sets out the trade honestly. And if the base layer is your concern more broadly, Docker base images: the hidden risk in your container stack is the companion piece.

FAQ

Is Temurin free for commercial use?

Yes. Adoptium distributes Temurin under the GNU General Public License version 2 with the Classpath Exception, and states the binaries are provided at no cost to use, forever. There is no field-of-use restriction and no commercial licence to negotiate, which is the main reason teams moved to it from Oracle JDK. Support and patching cadence, however, are separate questions from licensing.

Should I run the JDK or the JRE image in production?

The JRE, in almost every case. The JDK includes javac, jshell, jlink and the full diagnostic toolset, none of which your running application needs, and all of which expand the attack surface and the image size. Build in a JDK stage, copy the artifact into a JRE stage. On Java 9 and later, a jlink runtime trims further by including only declared modules.

Does Temurin passing the TCK mean the container image is secure?

No, and the distinction matters. The Java Compatibility Kit verifies that the runtime correctly implements the Java specification. It says nothing about the Ubuntu or Alpine layer packaged alongside it, which is where the great majority of reported CVEs originate. Compatibility certification and vulnerability posture are independent properties, and only one of them is being tested.

Is Alpine safe to use for Java?

Usually, with testing. The JVM insulates most application code from the musl-versus-glibc difference, so Alpine is less hazardous for Java than for Python or Node. Problems concentrate in JNI libraries, native agents, APM instrumentation and profilers compiled against glibc. Validate your observability stack specifically, because that is where musl incompatibility tends to surface first.

How often should a Java base image be rebuilt?

Whenever an upstream fix lands in any package it contains, not on a fixed monthly schedule. Roughly 89% of CVEs already have a fix available upstream, yet about 40% of fixable vulnerabilities remain unresolved past six months. The delay is almost never the absence of a patch - it is the absence of a process that rebuilds and revalidates on every advisory.