From Java 11 forward, TCK-verified OpenJDK builds are a drop-in replacement, and your entire compatibility test plan collapses to six named Java 8-era edge cases
Oracle sells the fear that leaving its JDK is a re-engineering project. In practice, all major distributions build from the same upstream source and pass the same TCK, so the risk surface is concentrated in JavaFX, Web Start, applets, Windows sound drivers on Java 8, JFR format versions, and JAXB removal. Testing those six specifically, rather than regression-testing 400 applications, is the difference between a 6-week migration and a 12-month one that never finishes before the October 2026 licensing cliff.
Prepared by Redress Compliance · August 24, 2026 · Oracle Java advisory. Migration and audit-defense engagements 2024 to 2026.
Executive summary
TCK conformance is a property of a specific built binary, not of a vendor brand, so your test evidence must name the exact build string and architecture you deploy.
Temurin, Corretto, Zulu and Liberica all publish TCK-verified builds certified against the Java SE specification, but a Temurin 21 x64 Linux build passing the JCK says nothing evidentiary about the aarch64 build you actually shipped to production.
Compatibility risk is almost entirely a Java 8 problem: from Java 11 onward Oracle JDK and OpenJDK feature sets are aligned, which means an estate already on 11, 17 or 21 has close to zero technical migration work.
If you are still on Java 8, you are not making one decision, you are making two at once, changing vendor and changing major version, and the version jump is where the real effort sits.
The six recurring breakers are named and finite: JavaFX (separate OpenJFX project), Java Web Start (removed in JDK 11), applets (unsupported by every OpenJDK vendor), Oracle's native Windows sound drivers for Java 8, JFR file format version handling in your APM tooling.
And JAXB/JAX-WS removal from the core in Java 11.
Each has a known remediation path, OpenWebStart, bundled OpenJFX from BellSoft, Windows sound drivers, external Maven dependencies, so the test plan is a checklist, not a discovery exercise.
The commercial clock is the real constraint: Oracle JDK 21 updates leave the permissive NFTC at the October 2026 Critical Patch Update, and a 12,000-employee enterprise on the Universal Subscription pays $1,188,000 per year at list regardless of install count.
That deadline means your test plan needs to be scoped to the six edge cases and completed in weeks, not scoped to full regression across every application and completed never.
What TCK verification actually certifies, and what it leaves to you
The Technology Compatibility Kit (TCK, delivered as the Java Compatibility Kit or JCK for Java SE) certifies one thing: that a specific built binary, on a specific architecture, conforms to the Java SE specification for a specific version.
It does not certify a vendor, a brand, a product line, or a support contract. Eclipse Temurin, Amazon Corretto, Azul Zulu and BellSoft Liberica all publish TCK-verified builds, and all of them compile from the same upstream OpenJDK source tree that Oracle itself uses to produce Oracle JDK.
That shared provenance, not vendor marketing, is the technical reason a swap from Oracle JDK 11 or later to a TCK-verified build is a drop-in replacement requiring no application code changes.
What TCK verification leaves to you is everything outside the specification: bundled extras (JavaFX, fonts, native drivers), the license under which you receive the binary, and the date at which your chosen vendor stops shipping updates for the version you standardized on.
| Distribution | TCK-verified | Extra quality gate | License | JavaFX bundled | Support end dates |
|---|---|---|---|---|---|
| Eclipse Temurin | Yes, Oracle JCK | Yes, AQAvit suite in addition to JCK | GPLv2 with Classpath Exception | No | Vendor/community-set |
| Amazon Corretto | Yes | None published beyond TCK | GPLv2 with Classpath Exception | No | Vendor-set (AWS) |
| Azul Zulu | Yes | None published beyond TCK | GPLv2 with Classpath Exception | Separate Zulu FX builds | Vendor-set (Azul) |
| BellSoft Liberica | Yes | None published beyond TCK | GPLv2 with Classpath Exception | Yes, Full builds | Vendor-set (BellSoft) |
| Oracle JDK | Yes | None published beyond TCK | NFTC then OTN (JDK 21 moves at the October 2026 CPU) | No | Oracle-set, license-gated |
The column the table cannot render is build-string discipline. TCK conformance attaches to the binary and the architecture, so "we run Temurin" is not a compatibility statement, and it will not survive an audit conversation or a vendor support escalation.
Record the exact build string (vendor, version, build number, architecture, OS) for every deployed runtime and store it alongside the vendor's published TCK attestation for that build. That artifact is what you produce when an application vendor claims your estate is unsupported.
The second unrendered point is that the license column is the only genuinely differentiating one. GPLv2 with Classpath Exception carries no per-user, per-processor or per-employee fee and no field-of-use restriction.
Oracle's NFTC is time-boxed by design: JDK 17 lost it in September 2024 at build 17.0.12, and JDK 21 loses it at the October 2026 Critical Patch Update. You are not choosing between technical qualities.
You are choosing between an identical binary with a permanent license and an identical binary with an expiring one. Our OpenJDK execution guide sequences that swap.
The six edge cases that account for nearly every real failure
From Java 11 forward, Oracle JDK and OpenJDK feature sets are compatible, which means the entire practical risk surface sits in Java 8-era estates and in a small set of components Oracle either never open-sourced or removed from the core.
Six items account for nearly every failure we see, and each one is a search-and-remediate task you can complete with a repository grep and a dependency scan, not a regression test cycle across hundreds of applications. Treat them as a checklist with named owners and closure dates.
JavaFX lives in the separate OpenJFX project and is absent from most OpenJDK binaries; if your desktop apps import javafx.*, either move to a distribution that bundles it (BellSoft Liberica Full) or add OpenJFX as an explicit dependency. Java Web Start was deprecated in JDK 9, removed in JDK 11, and remains closed-source.
OpenWebStart is the replacement, and IcedTea-Web 1.8.x/2.0.x works with Temurin 8 builds but carries no tests for OpenJDK 11+ JNLP and is not bundled with Temurin 11, so JNLP-dependent applications need an explicit proof-of-function test rather than an assumption. Applets are not supported by any OpenJDK vendor; if you still run them, that is a rewrite decision, and it exists whether or not you leave Oracle. Native Windows sound drivers shipped in Oracle JDK 8 only.
The remediation is to fall back to the Windows drivers, which affects a handful of media and telephony applications and almost nothing else. The Lucida font family shipped in Oracle JDK 8 and earlier and is absent downstream.
Substitute a licensed equivalent and expect layout drift in fixed-width PDF and report generation. JAXB and JAX-WS were removed from the core in Java 11 and must be re-added as Maven or Gradle dependencies, which is a build-file edit, not a code change.
One further item needs judgment rather than a rule: Oracle JDBC TDE extensions require case-by-case assessment against your database configuration.
Notice what is not on the list: application code, framework behavior, garbage collector tuning, class loading, or bytecode compatibility. Oracle's account teams routinely imply that leaving the Oracle JDK is a re-engineering effort.
In our negotiation practice the compatibility objection is raised most often at the point a buyer signals it is costing the alternative, and it is raised in the abstract, never with a named failing component. Ask for the component name.
If the answer is a category rather than a class or package, you are being sold to. The comparison of the six Java options sets out which of them need no migration work at all.
Defend an Oracle Java audit without overpaying
Oracle now audits Java SE on employee count, not installs, which can multiply the bill several times over. How to defend the notice and exit to OpenJDK.
Get the white paper →Testing JFR, monitoring and observability continuity
The tooling layer is where migrations get delayed, not the application layer, because nobody owns it until it breaks.
Java Flight Recorder was decoupled from Oracle JDK and contributed to OpenJDK, and it ships in every version of Temurin; Java Mission Control is a separate download from the Eclipse Mission Control project rather than a bundled binary. Two artifacts confuse teams here.
First, the unlock_commercial_features flag still exists and still parses, but it does nothing, because JFR was a commercial feature only in Oracle JDK before 11. Engineers who see the flag in a startup script and conclude they are running something Oracle-only are reading a fossil.
Second, JFR file format v2.0 spans Oracle JDK 11 and later, OpenJDK 11 and later, and Azul JDK 8 and 11 and later, which means the recording format your APM ingests is a property of the format version, not the vendor logo.
Test this before the cutover, not after: emit a recording from the candidate build, load it into your monitoring vendor's ingestion path, and confirm the parse.
The same discipline applies to the rest of the observability stack, which is where we see most of the real friction in Oracle Java to OpenJDK migration work.
- Validate that your APM agent version supports the JFR format the new build emits, in writing from the vendor, before the change window.
- Diff GC log formats and flag names between old and new builds; unified logging changed in Java 9, so Java 8 estates carry double the risk here.
- Re-verify JVM tuning parameters that were tuned against Oracle JDK defaults, particularly heap sizing and GC selection, and record before and after baselines.
- Confirm JMC is installed and licensed separately as an Eclipse project, and remove any assumption that it arrives with the JDK.
- Check dashboards and alert thresholds that key off metric names, since a renamed GC or thread-pool metric silently breaks alerting without failing a test.
Why the compatibility argument is a negotiation tactic, not a technical finding
When an application owner says "we have applications that cannot move," they are almost never reporting a technical finding. They are reporting the state of their inventory.
In twenty-five years of these engagements, the sentence has meant "I have not looked" far more often than it has meant "I looked and found an Oracle-only dependency." The distinction matters commercially, because Oracle's model is built on you never resolving it.
Start with the metric. Under the Employee model, a 12,000-employee enterprise pays $1,188,000 a year at list whether it runs four Oracle JDK installs or four thousand.
Oracle's own price list defines Employee to include agents, contractors, outsourcers and consultants supporting internal operations, and the count must at minimum equal headcount at the order effective date. There is therefore no version of precise scoping that helps Oracle.
A sales team that once had a reason to argue about processor counts now has none, which is why the conversation moved from "how much Java do you run" to "how disruptive would it be to stop." Fear is the only variable left that moves the deal.
The technical reality does not support the fear. From Java 11 forward, Oracle JDK and OpenJDK features are compatible, and the major distributions build from the same upstream source and pass the same TCK.
The genuinely Oracle-only surface is narrow: JavaFX packaging, Web Start, applets, Windows sound drivers on Java 8, Lucida fonts, and the Oracle JDBC TDE extensions that need case-by-case assessment. That is a list you can enumerate and test.
It is not a list that justifies a seven-figure annual subscription across an entire employee base.
The fear survives because two separate problems get conflated. A Java 8 estate faces a version jump, with JAXB and JAX-WS removed from the core and re-added as Maven or Gradle dependencies, plus the desktop stack issues. A vendor switch on Java 11 or later faces essentially nothing.
When engineering reports "Java migration is hard," it is usually describing the first problem while procurement hears an argument against the second. Oracle does not have to make that conflation. It only has to leave it uncorrected.
The practical consequence is that an unfinished inventory becomes the internal justification for renewal. Procurement does not lose the argument to Oracle. It loses it to its own application owners, three weeks before the renewal date, when nobody can certify that the estate is clean.
Oracle's account team never has to make the case; your own risk register makes it for them.
The counter-move is to invert the burden of proof. Application owners do not get to assert a blocker; they must name the specific Oracle-only API, binary or driver, with a file path or class name. "We have not tested it" is a scheduling item with an owner and a date, not a blocker.
Anything that cannot be named goes into the migrate-by-default pool. That single procedural change typically collapses a claimed blocker list of dozens down to a handful, and it is the discipline that separates a six-week program from one that never finishes.
One contract trap deserves naming. The NFTC states that if you have a subscription agreement in place for any version of Java, that agreement is in force and NFTC cannot be applied.
Teams planning to sit on JDK 21 free updates through September 2026 while an active subscription runs are relying on a permission they have already contracted away. Check the paper before you build the plan.
Building a test plan sized to the risk, not to the fear
The method is triage, not coverage. Sort every application into three buckets before a single test runs.
Bucket one is anything already on Java 11 or later, server-side: build, boot, run the existing smoke suite, done, because from Java 11 forward Oracle JDK and OpenJDK feature sets are compatible and the binaries derive from the same upstream source.
Bucket two is Java 8 server-side: run the same smoke test plus the six-case checklist, and attach a version decision to each application (stay on OpenJDK 8, or fold the upgrade to 17 or 21 into the same change window).
Bucket three is desktop: JavaFX, JNLP, applets, anything that draws a window or plays a sound on Windows. That is the only bucket that needs real engineering, and in our experience it is 3 to 8 percent of a typical estate by application count.
The rationale for parallel-run instead of full regression is the shared source point: you are not testing a different implementation, you are testing a different build of the same code, so what you are actually hunting is packaging deltas (missing OpenJFX, missing Lucida fonts.
Absent Java 8 Windows sound drivers) and removed modules (JAXB and JAX-WS, which you re-add as Maven or Gradle dependencies).
Record the exact `java -version` build string for every node, before and after, and capture JFR and GC baselines on both so a performance complaint three weeks later has a comparator instead of a hunch. Then timebox it.
The OpenJDK execution guide sequences this work in six to eight weeks for most estates.
The deadline is not negotiable and it is closer than the calendar suggests. Oracle JDK 21 updates stay under the NFTC through the September 2026 CPU; from the October 2026 Critical Patch Update they move to the OTN license, which means paid.
The JDK 17 precedent is already on the record: NFTC expired September 2024, last free build 17.0.12 in July 2024, and organizations that were still testing in August 2024 spent the next year patching under a license they had not read.
Work backwards from October 2026, not forwards from today. If bucket three needs a Web Start replacement (OpenWebStart) or an OpenJFX bundling decision, that is a procurement and packaging exercise with lead time, so it starts first even though it affects the fewest applications.
Buckets one and two run in parallel behind it. If your remediation plan cannot close before the CPU date, you are buying a bridging subscription at Employee metric pricing, and that is a very expensive way to pay for a project plan.
Evidence base: what we see across migration engagements
The Employee metric caps installs at 50,000 processors, excluding desktops and laptops, and exceeding it requires an additional license.
A 28,000-count organization (23,000 employees plus 5,000 contractors) at $6.75 per month, per head, per Oracle's published price list.
Three patterns repeat across engagements. First, most claimed blockers dissolve on inventory. Application owners escalate "we cannot leave Oracle Java" and, when asked which specific API or behavior they depend on, produce nothing beyond a vendor support statement written in 2019.
The named technical failures are a short list, and they cluster in Java 8.
Second, desktop Java is the only consistently painful category, and it is painful for the same reasons every time: Web Start was removed in JDK 11 and remains closed source, no OpenJDK vendor supports applets, JavaFX lives outside the OpenJDK binary.
And IcedTea-Web has no test coverage for JNLP on 11 and later.
Budget engineering hours there and nowhere else. Third, and this is where buyers pick the wrong vendor, "LTS" is a vendor convention rather than an upstream OpenJDK commitment.
Microsoft, Corretto, Zulu, Temurin and Red Hat publish different end dates for the same Java version, so the selection criterion is support-window arithmetic against your own refresh cycle, not brand familiarity.
Compare the published dates directly, as set out in our review of the six Java options and the two that need no migration.
The backdrop makes the timing sharper: through 2026, Oracle's soft outreach is converting into formal audit notices from Global Licensing and Advisory Services, the renamed LMS function.
A completed migration with recorded build strings and dated evidence is the cheapest audit defense available, and it costs a fraction of one year of Employee metric subscription.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
Your first five moves
- Finish the install inventory before a single test runs, because an estate you cannot enumerate cannot be scoped, and Oracle's Employee metric bills your headcount regardless of whether you found four installs or four thousand.
- Classify every install by Java version first, separating the pure vendor switch (Java 11 and above, where Oracle JDK and OpenJDK features are compatible) from the genuine version jump, so you stop paying regression-test effort on builds that carry no risk.
- Run the six-case checklist only against Java 8 estates, covering JavaFX, Web Start and applets, Windows native sound drivers, JFR format version, and JAXB/JAX-WS removal, and treat everything else as passing until a named failure says otherwise, following the sequencing in our Oracle Java to OpenJDK execution guide.
- Select the distribution on support end date arithmetic, not brand, and record the exact build string of each binary you deploy as your TCK evidence, since conformance is a property of a specific built artifact rather than a vendor logo; the six Java options comparison sets out the end-date math.
- Hold your migration plan against the October 2026 NFTC expiry for JDK 21, and keep the subscription conversation alive as leverage into Oracle's Q4 (March to May), when in our negotiating experience discounting authority is at its widest, while never signing a subscription that would void NFTC rights across your remaining free versions.
Frequently asked questions
Does a TCK-verified OpenJDK build guarantee my application will run unchanged?
It guarantees the build conforms to the Java SE specification for that version, which is why migration is typically drop-in from Java 11 forward.
It does not cover Oracle-proprietary additions that were never part of the specification, such as JavaFX, Java Web Start, applet support, or Oracle's native Windows sound drivers for Java 8.
Verify the exact build and architecture you deploy, because TCK conformance attaches to a specific binary, not to a vendor brand.
Which JDK distributions publish TCK-verified builds?
Eclipse Temurin, Amazon Corretto, Azul Zulu and BellSoft Liberica all publish TCK-verified builds certified compatible with the Java SE specification for their version. Temurin adds a second gate, requiring builds to pass the AQAvit quality verification suite after JCK certification.
All are licensed GPLv2 with Classpath Exception, permitting free commercial use with no per-user, per-processor or per-employee fees.
What actually breaks when moving from Oracle JDK to OpenJDK?
Six recurring items: JavaFX (in the separate OpenJFX project, bundled by BellSoft but not by most), Java Web Start (removed in JDK 11, replaced by OpenWebStart), applets (unsupported by every OpenJDK vendor), Oracle's native Windows sound drivers for Java 8.
The Lucida font family from Oracle JDK 8 and earlier, and JAXB/JAX-WS removal from the core in Java 11.
Oracle JDBC TDE extensions also need case-by-case assessment. Each has a known remediation path.
Do I lose Java Flight Recorder if I leave Oracle JDK?
No. JFR was decoupled from Oracle JDK and contributed to OpenJDK, and it ships in all versions of Temurin, with JMC available separately from the Eclipse Mission Control project.
The unlock_commercial_features flag persists for compatibility but does nothing, because JFR was only a commercial feature in Oracle JDK before 11. Test that your APM tooling ingests JFR file format v2.0, which spans Oracle JDK 11+, OpenJDK 11+ and Azul JDK 8/11+.
How long do I have before Oracle JDK 21 stops being free?
JDK 21 updates through and including September 2026 are available under the No-Fee Terms and Conditions license. From the October 2026 Critical Patch Update, further Oracle JDK 21 updates are planned to move to the Java SE OTN license, the same one covering Java 8, 11 and 17.
The precedent is JDK 17, where NFTC expired in September 2024 with build 17.0.12 the last free update.
Can I stay on NFTC builds if I already have an Oracle Java subscription?
No. The NFTC explicitly states that if you have a subscription agreement in place for any version of Java, that agreement is in force and NFTC cannot be applied.
Organizations that renew a Universal Subscription while planning to fall back on free NFTC builds are relying on a route the license text closes. Check your agreement wording before you build a migration timeline around free updates.
How should I choose between Temurin, Corretto, Zulu and Liberica?
Not on TCK status, since all four publish TCK-verified builds from the same upstream source.
Choose on support end dates, because the LTS label is a vendor convention rather than an upstream OpenJDK commitment, and Microsoft, Corretto, Zulu, Temurin and Red Hat publish different end dates for the same Java version.
Match the vendor's published end date to your application's expected life, and record the exact build string you deploy for audit evidence.
