Same source tree, different file. This is the head to head at the artifact level: what is identical, what genuinely differs, and the short list of things that actually break on a swap.
Oracle JDK and a mainstream OpenJDK build of the same release are not the same file, yet they come from the same source and Oracle itself calls them interchangeable. This page runs the head to head at the binary level: what is identical, what genuinely differs, and what actually breaks on a swap.
The technical question is narrower than most buyers expect. Oracle and every mainstream distributor compile from the same source tree at the OpenJDK project, and for Java 11 onward Oracle's own engineering blog describes its builds and the OpenJDK builds as functionally identical and interchangeable.
That does not mean the two files are byte identical. They are not. It means the differences are enumerable, and this page enumerates them rather than gesturing at risk.
White Paper · Oracle Java
The buyer side route out of the Java SE subscription. Read it free.
No, they are not the same file, but at Java 11 and later they are compiled from the same source and Oracle publishes the differences itself. That list is the honest starting point for any technical risk conversation.
Oracle's engineering post Oracle JDK Releases for Java 11 and Later names the divergences that survived the Java 11 convergence. Read it with a single question in mind: does this change how my application behaves at runtime?
Oracle's own difference list, scored for runtime impact
| Difference Oracle names | What it actually is | Changes runtime behaviour? |
|---|---|---|
| Version banner text | Oracle prints Java(TM) SE Runtime Environment, OpenJDK builds print OpenJDK Runtime Environment | Only if your code parses it |
| UnlockCommercialFeatures flag | Oracle JDK warns and continues, OpenJDK errors and refuses to start | Yes, if the flag is still in a startup script |
| Advanced Management Console usage logging | Oracle telemetry that reports JVM usage to an Oracle console | No, and losing it is usually welcome |
| Signed cryptography providers | Oracle JDK requires third party JCE providers to be signed, OpenJDK does not enforce it | Yes, but it relaxes on migration |
| javac release targeting on 9 and 10 | Older Oracle targets exposed extra modules such as JavaFX and JNLP | Compile time only, and moot at 11 and later |
| Packaging and installers | Oracle ships branded installers and a separate JRE layout, OpenJDK ships archives | No, but it breaks install scripts |
The parts that decide whether your application runs are shared source. Nothing on this list has a vendor specific implementation in a mainstream HotSpot build.
Java 8 is a different conversation, and this is the part most comparison articles skip. The convergence Oracle describes happened at Java 11, so an estate still on 8 is comparing genuinely different products.
A short and repeatable list, and it is almost never application code. In the estate reviews behind this page the same seven items accounted for effectively every pilot failure.
The real difference list, with the failure mode and the test that catches it
| What differs | How it fails | The test that catches it |
|---|---|---|
| Trust store contents | TLS handshake fails at runtime against one specific endpoint | Diff the cacerts subject list between old and new, then connect to every outbound endpoint |
| Bundled JavaFX or Web Start on 8 | Class not found at startup | Grep the codebase for javafx and jnlp imports |
| UnlockCommercialFeatures in a start script | JVM refuses to start on OpenJDK | Grep every start script and container entrypoint for the flag |
| Vendor string parsing | Licence check or feature gate in the application misfires | Grep for java.vendor and java.runtime.name reads |
| Font rendering and locale data | Server side PDF or image output shifts by a pixel or a glyph | Render a reference document and compare, only for estates that generate documents |
| Install layout and path shims | Automation that hardcoded an Oracle path or registry key breaks | Search configuration management for hardcoded JAVA_HOME values |
| OpenJ9 instead of HotSpot | Tuning flags rejected, heap and startup profile change | Confirm the build is HotSpot based before you call it like for like |
Every distributor decides what goes in cacerts. Oracle ships the set from its own root certificate program, Eclipse Temurin ships the Mozilla list, and Amazon Corretto ships a set curated by Amazon.
Those sets overlap heavily but not completely. The failure is nasty because it is silent until the first call to the one endpoint whose issuer is missing, which may be a quarterly file transfer rather than a login page.
The fix is mundane. Export the subject list from the outgoing JDK, diff it against the incoming one, and import anything your estate depends on. Do this once at the standard level rather than per application.
Not every build labelled OpenJDK is a HotSpot build. IBM Semeru and older AdoptOpenJDK OpenJ9 builds use the Eclipse OpenJ9 virtual machine, which is a genuinely different implementation.
OpenJ9 can be an excellent choice, particularly for memory density in containers. It is simply not a drop in replacement in the way Temurin, Corretto, Zulu, Liberica and the Microsoft build are, because the tuning flags and heap behaviour differ.
If you want the zero surprise path, restrict the shortlist to HotSpot builds and treat OpenJ9 as a separate evaluation. The distribution choice guide covers how to write that shortlist as a specification.
Three artifacts settle it, and you need all three because each one can be wrong on its own. This matters twice: once for your migration evidence, and once because it is exactly what an Oracle review keys off.
What each artifact proves, and what it does not
| Artifact | Proves | Does not prove |
|---|---|---|
| Version banner | Oracle branded build or not | Which vendor, or whether the build is licensable |
| release file | The distributor and the exact build | When it was installed or by whom |
| Package or registry record | Install date, patch level and host | Anything about an unzipped copy with no package record |
| All three together | A defensible position on scope and dates | Copies inside third party application bundles |
Oracle publishes its own GPL licensed builds of OpenJDK, and those print the OpenJDK banner. A banner check therefore cannot distinguish a Temurin install from an Oracle build of OpenJDK.
That distinction matters, because Oracle's OpenJDK builds stop receiving updates six months after release. An estate that standardized on them is on a treadmill rather than a destination, even though nothing about it is licensable.
Capture all three artifacts before you remove anything. Install date, patch level and host record are the evidence that bounds any retroactive claim, and deleting the binary first destroys it. The CI and workstation cleanup guide sets out the capture order, and the Oracle Java audit response playbook covers what happens if a review starts before you finish.
Yes for a release inside its maintained window, because the fixes originate in the same upstream update project and land on the same quarterly cycle. Parity ends at the version tail, not at the vendor.
Oracle publishes a critical patch update four times a year, in January, April, July and October. The same fixes flow through the OpenJDK updates project for that release line, and each distributor builds, tests and ships from there.
The variable is lag, not content. Mainstream distributors publish within days of the Oracle date, and that lag is measurable, so write it into your standard as a service level rather than assuming it.
When a release leaves its free window, Oracle continues to patch it for subscribers while the community updates project continues under a different maintainer. The two sets can drift on backports for old lines.
This is a real consideration for a Java 8 or Java 11 estate and close to irrelevant for a Java 17 or later estate. Check the window for your specific release on the Oracle Java SE support roadmap before you treat the two as equivalent.
Because you are not buying the code. You are buying a licence to run Oracle's build outside its free window, plus a support contract. Oracle prices the Java SE Universal Subscription against your headcount, not your usage.
The Java SE Universal Subscription counts every employee in the organization, not every Java user or every server. One remaining Oracle install therefore prices the whole workforce.
State that once and plan around it. A migration that reaches 95 percent of the estate and stops delivers zero licence saving, which is why the discovery step matters more than the technical step.
The binaries converged in 2018. The prices did not. That gap is the whole commercial argument, and it does not require a single technical concession to make.
The full metric mechanics, the price ladder and the modelled cost of each path sit elsewhere in this library. See the Oracle Java licensing pillar for the metric, the Oracle Java licensing benchmark for what peers pay, and three migration patterns cost modeled for the five year comparison.
One thing, precisely: a contractual counterparty who is obliged to fix a defect in the runtime itself. Everything else you keep, and that counterparty is purchasable from several vendors.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
When something you cannot change depends on it specifically. That is a narrow set, and it is worth testing rather than assuming, because assumed dependencies are the most expensive kind.
Oracle GraalVM and the Enterprise tier compilers are the clearest example, and they are a separate product decision rather than a JDK decision. Test whether your workload actually uses the Oracle specific path before you accept the dependency.
An independent software vendor that certifies only Oracle JDK creates a real obligation, particularly in regulated estates where the certification matrix is auditable. Ask the vendor in writing whether a HotSpot OpenJDK build of the same release is supported.
In practice most vendors either already support it or will confirm it in writing when asked. The written answer is worth obtaining early, because it is also the artifact that unblocks your internal risk committee.
The standard advice is to run a full application regression programme against the new runtime before committing. We disagree, and the estate evidence is fairly blunt about it. The set of things that can differ between two HotSpot builds of the same release is enumerable and short, and a functional regression suite exercises almost none of it. Teams spend a quarter re running tests that were always going to pass, then get caught by a trust store gap that no functional test would ever have found. Test the seven item list directly, in a soak environment, against real outbound endpoints and real document rendering. That takes days, not a quarter, and it actually catches the failures.
Not the same file, but built from the same source, and Oracle describes its Java 11 and later builds as functionally identical and interchangeable with OpenJDK builds. The virtual machine, the class library, the compiler and the garbage collectors are shared code. The differences are in branding, packaging, telemetry and a handful of edge behaviours.
Oracle names six differences for Java 11 and later, and only two touch runtime behaviour. The UnlockCommercialFeatures flag warns on Oracle and errors on OpenJDK, and Oracle enforces signing on third party cryptography providers while OpenJDK does not. The rest is the version banner, Oracle telemetry, an old compile time targeting quirk and installer packaging.
Rarely, and when it does the cause is usually the trust store rather than the code. Differences in the bundled root certificate set can fail a TLS handshake against one specific endpoint at runtime, with no build time warning. Diff the certificate subject lists before you cut over and most of the risk disappears.
Check three things, not one. The version banner distinguishes an Oracle branded build from an OpenJDK build, the release file at the top of JAVA_HOME names the actual distributor in its IMPLEMENTOR field, and the package or registry record carries the install date and patch level. Capture all three before removing anything.
No, not for the same release on a HotSpot build. Both run the same HotSpot virtual machine with the same just in time compilers, the same garbage collectors and the same defaults. Measured differences in a benchmark are almost always configuration or version differences rather than vendor differences.
Yes for a release inside its maintained window, because the fixes come from the same upstream update project on the same quarterly cycle. Mainstream distributors publish within days of Oracle's critical patch update date. Write that lag into your standard as a measurable service level rather than assuming it.
No, and this is the exception that matters. The convergence Oracle describes happened at Java 11. On Java 8, OpenJDK builds shipped an empty trust store until the root certificates were contributed at JDK 10, Flight Recorder was an Oracle paid feature until it was backported at update 262, and JavaFX and Web Start were bundled only by Oracle.
Effectively yes. The Java SE Universal Subscription counts every employee in the organization rather than every Java user, so one remaining Oracle install keeps the whole workforce in scope. A migration that reaches 95 percent of the estate and stops delivers no licence saving at all.
The renewal and exit map for Oracle Java SE: employee metric math, OpenJDK and Azul paths, and the timing that protects leverage.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
Oracle Java and OpenJDK are the same engine. The only question worth asking is whether your estate has a reason to pay per employee for it.
