OpenJDK vs Oracle JDK: the complete comparison.

The most consequential fact in Oracle Java licensing is also the least understood: Oracle JDK and OpenJDK are built from the same source code. For the overwhelming majority of enterprise workloads they are functionally interchangeable — yet one can carry a subscription priced against your entire headcount, and the other is completely free. This comparison sets out exactly how they differ, where they are identical, and what that means for an enterprise deciding what to run. Across more than 340 Java licensing engagements, recognising this equivalence is the single insight that has unlocked the most savings.

Same source, different distributions

OpenJDK is the official open-source reference implementation of the Java SE platform. It is the project where Java itself is developed — and Oracle is the largest single contributor to it. When a new Java version is released, the work happens in OpenJDK.

Oracle JDK is Oracle's own branded build of that OpenJDK source. It is not a separate, superior Java. It is one distribution among many, all compiled from substantially the same code. Amazon, Microsoft, Azul, Red Hat, BellSoft, the Eclipse Adoptium project and others each produce their own builds of the identical source. The phrase that captures it best: OpenJDK is the recipe; Oracle JDK and the others are different bakeries making the same cake.

This is why the comparison is not really “OpenJDK vs Oracle JDK” in the sense of two rival products. It is a comparison of distributions of one shared platform — and the meaningful differences are about licensing, support, and packaging, not about the Java underneath.

The licensing difference

This is the difference that matters most, and it is stark.

OpenJDK builds from vendors such as Eclipse Adoptium, Amazon, Azul, Microsoft, Red Hat and BellSoft are released under the GNU General Public License version 2 with the Classpath Exception (GPLv2+CPE). In plain terms: they are free to download, free to run in production, free to redistribute, with no per-employee fee, no usage metric, and no audit exposure. You can run them on ten servers or ten thousand at zero licence cost.

Oracle JDK is licensed differently depending on the version and the date:

• Recent versions (Oracle JDK 17 and later) are issued under the Oracle No-Fee Terms and Conditions (NFTC) — free for a defined window, after which continued use of that version requires a paid subscription.
• Versions in the Java 11–16 range, and Oracle JDK 8 updates from 2019 onward, fall under the Oracle Technology Network (OTN) licence, which permits development and testing but charges for production and commercial use.
• A paid Java SE Universal Subscription covers Oracle JDK use, and it is priced on the employee metric — your entire workforce, not your Java users.

The consequence: the same Java application, on the same server, costs nothing on an OpenJDK build and can cost a per-employee annual fee on Oracle JDK. The bytes that run are nearly identical. The invoice is not.

Technical equivalence

If the licensing differs so dramatically, the obvious question is whether the software differs too. For practical enterprise purposes, the answer is no.

All distributions that pass the Java SE Technology Compatibility Kit (TCK) are certified to behave identically to the specification. The major OpenJDK distributions — Temurin, Corretto, Zulu, Liberica, Microsoft Build of OpenJDK, Red Hat build — are TCK-certified. An application compiled and tested against Oracle JDK at a given version will run on a TCK-certified OpenJDK build of the same version without code changes. Byte-for-byte the builds are not identical, because each vendor compiles independently, but they are compatible: same language, same APIs, same bytecode, same behaviour.

For years there were a handful of genuine technical differences — Oracle JDK historically bundled tools and components such as Java Flight Recorder, Mission Control, the Z Garbage Collector and Application Class-Data Sharing that were not in early OpenJDK builds. Oracle has since contributed essentially all of these to OpenJDK, and they are present in modern OpenJDK builds. The technical gap that once existed has, for current Java versions, effectively closed.

The realistic position for an enterprise: for the vast majority of applications, an OpenJDK build is a drop-in replacement for Oracle JDK at the same major version. The work of migrating is testing and rollout discipline — not rewriting software. Our step-by-step migration guide covers how to do that testing.

Security updates and patches

A common worry is that free Java means slow or absent security updates. It is unfounded.

Java security fixes — the quarterly Critical Patch Updates — are developed in the OpenJDK project itself, in the open. Every reputable OpenJDK distribution incorporates those fixes and ships updated builds on the same quarterly cadence as Oracle. Amazon Corretto, Eclipse Temurin, Azul Zulu and the others release their patched builds promptly after each quarterly update.

What does differ is how long each vendor maintains a given version. Long-Term Support (LTS) versions of Java — 8, 11, 17, 21, and the newer LTS releases — receive extended updates, but the exact end-of-support date varies by distribution. Eclipse Adoptium, Amazon, Azul and others each publish their own support roadmaps, and several commit to multi-year support windows for LTS versions that are comparable to, and in some cases longer than, Oracle's. The practical task for an enterprise is to pick a distribution whose support roadmap matches how long it intends to stay on a given Java version — not to assume Oracle is the only source of timely patches. It is not.

Support models

“Free” refers to the licence, not to commercial support — and the two should not be confused.

Every major OpenJDK distribution can be run with no support contract at all: you simply consume the free builds and updates. Many organisations do exactly this for the bulk of their estate. But for workloads where a vendor SLA, a support hotline, or formal incident response is required, commercial OpenJDK support is readily available — Azul, Red Hat, BellSoft, IBM and others sell support subscriptions for their builds, and Amazon backs Corretto for customers on AWS.

The key point for cost comparison: commercial OpenJDK support is generally priced per-server, per-core, or per-instance — tied to what you actually run. Oracle's Java SE subscription is priced per-employee, tied to your headcount. For an organisation with a modest Java footprint and a large workforce, paid OpenJDK support for the workloads that need it is typically a fraction of the cost of an Oracle subscription that prices Java against everyone on the payroll.

The leading OpenJDK distributions

Several free, production-grade OpenJDK distributions are widely used in enterprises:

All are TCK-certified, all ship quarterly security updates, and all are free to run in production under GPLv2+CPE. The choice between them is a matter of support roadmap, platform fit, and organisational preference — not of whether they are “real” Java. They all are.

The cost comparison

The cost difference is best understood through the metric. Oracle's Java SE Universal Subscription multiplies a per-employee monthly rate by the organisation's total employee count. The bill is therefore driven by headcount, and is almost completely disconnected from how much Java the organisation actually runs.

Consider an organisation of 5,000 employees that runs Java in a few dozen applications. On the Oracle employee metric, it licenses all 5,000 employees — an annual figure well into six or seven figures — even though only a small fraction of staff ever interact with a Java application. On free OpenJDK builds, the same estate costs nothing in licensing. If the organisation wants commercial support for, say, twenty critical Java servers, it pays for support on twenty servers — a number measured in thousands, not millions.

This is why, for most organisations, the honest cost answer is not “OpenJDK is cheaper” but “OpenJDK removes the cost almost entirely.” The recurring per-employee Oracle bill is replaced by, at most, modest per-server support for the workloads that genuinely warrant it. Over a three-to-five-year horizon the gap is large enough that migration project costs are recovered quickly. The Oracle Java renewal guide works through the renew-versus-exit economics in detail.

When Oracle JDK is genuinely needed

An honest comparison must say when Oracle JDK is the right choice — and the genuine cases are narrow:

• A third-party product mandates it. A small number of commercial applications are certified or contractually supported only on Oracle JDK. Where a vendor genuinely requires it, that workload may need Oracle JDK — though it is always worth challenging whether the requirement is real or merely a default.
• A specific Oracle entitlement already covers it. Some licensed Oracle products include a restricted-use Java SE entitlement for that product. Using Oracle JDK within that entitlement is appropriate — see Oracle products that include Java SE.
• A genuine need for Oracle's specific commercial support. Rare, given the maturity of commercial OpenJDK support, but possible for some organisations.

Crucially, these cases usually affect a handful of workloads — not the whole estate. And because the Universal Subscription is priced on total headcount regardless of how few installations you keep, retaining Oracle JDK for even one workload can mean paying the full headcount-based bill. That arithmetic is exactly why a clean, complete migration is so often the better answer than a partial one.

Choosing a distribution

If the comparison points you toward OpenJDK — as it does for most enterprises — choosing among the distributions comes down to a few practical questions:

• Support roadmap. How long does the distribution commit to updating the Java LTS versions you run? Match it to how long you intend to stay on each version.
• Platform fit. Some distributions integrate naturally with a particular cloud or OS. If your estate is heavily AWS, Azure, or Red Hat, the aligned distribution may simplify operations.
• Support need. Decide which workloads, if any, warrant a paid support contract, and choose a distribution that offers it on per-server terms.
• Standardisation. Picking one primary distribution across the estate simplifies patching and governance. Many organisations standardise on one and allow a second only where a platform demands it.

Frequently asked questions

This article is general information comparing Java distributions, not legal advice. Licensing terms and support roadmaps change; consult a qualified independent Java licensing specialist on your specific situation.