By ByteBot
Java 11’s Oracle Extended Support expires in September 2026 — three months from now. If your team hasn’t started migrating, you’re already behind. But that single deadline is just the leading edge of a much larger problem. Between 2029 and 2032, every mainstream Java LTS version will hit end-of-support in a single three-year window. Java 17, Java 8, Java 21, and Java 11 — all expiring in sequence within a span most enterprise planning cycles treat as the distant future. The developer community named it the “Java LTS support cliff” after a Slashdot thread went wide two weeks ago. The name fits. The problem is that most enterprise teams are still treating these deadlines as if they arrive one at a time.
The Timeline Is Worse Than It Looks
Here is the actual expiry schedule for the four most widely deployed Java LTS versions, per the Oracle Java SE Support Roadmap:
- Java 11 Extended Support (paid Oracle): September 2026 — the immediate crisis
- Java 17 Oracle support: September 2029
- Java 8 Oracle Extended Support: December 2030
- Java 21 Oracle Extended Support: September 2031
There is a twist most migration planning doesn’t account for: Java 11 and Java 21 free Oracle support both expire this September. Not 2029. September 2026. Teams moving to Java 21 as their migration target in 2026 are landing on a version whose free Oracle binary support expires within months of deployment. If you are mid-migration to Java 21 right now, you need a plan for what comes next — specifically, Java 25.
Why Java 21 Is No Longer the Right Target
Java 25 LTS shipped in September 2025. Its free Oracle NFTC support runs until 2028, a full two years beyond Java 21’s free window. Beyond the support runway, Java 25 is technically the better platform: it resolves the virtual thread pinning issue from Java 21 (JEP 491) — meaning synchronized blocks no longer trap carrier threads under load. It delivers 22% memory savings and Spring Boot 3.4+ and Quarkus 3.x both support it without configuration gymnastics.
For teams already deep in a Java 21 migration: finish the hop, then plan the move to Java 25 within the next 12 months. For teams just starting a migration in mid-2026: skip Java 21 and target Java 25 directly.
Sequential Migration Is a Plan That No Longer Works
The traditional enterprise approach — move one application at a time, version by version, one quarter at a time — assumes staggered deadlines. It works when you have five years between major LTS expirations. It does not work when four versions expire in three years.
Run the math: an enterprise with 200 Java applications distributed across versions 8, 11, 17, and 21 cannot migrate all of them to Java 25 sequentially while meeting each deadline. The three-year window becomes impossible the moment you account for test cycles, framework compatibility audits, and staging deployments. As InfoWorld noted: the real constraint is people, not frameworks. Parallel modernization requires parallel capacity — and most organizations haven’t budgeted for it.
The Azul 2026 State of Java Survey — 2,039 respondents across five continents — found that 81% of enterprises are already migrating away from Oracle JDK to non-Oracle OpenJDK distributions, and 92% express concern about Oracle Java pricing. These aren’t small shops hedging. These are companies that ran the numbers on Oracle’s licensing model and decided the risk is no longer acceptable.
The Real Cost of Waiting
For developers used to treating Java version upgrades as an ops concern, here is what belongs in your quarterly planning:
- Unpatched CVEs: Oracle issues quarterly Critical Patch Updates. Applications on EOL Java versions receive none of them.
- Compliance failure: PCI DSS, HIPAA, and FISMA all require software under active vendor support. Running EOL Java in a regulated environment is an audit finding.
- Oracle license audit exposure: Running Oracle JDK without an active subscription creates liability. Oracle audits are not hypothetical — they are a well-documented enterprise risk.
- Performance drag: Legacy JVMs require an estimated 20-40% more compute for equivalent workloads compared to modern JVM versions, making cloud cost optimization nearly impossible.
What to Do Now
Three steps, in order:
1. Take inventory. Run an audit of every Java runtime across your dev, test, and production environments. Most enterprises do not have an accurate count. Tools like Azul’s runtime discovery or even a scan of CI pipeline configs will surface more surprises than expected.
2. Triage by urgency. Java 11 apps with Oracle licensing are your emergency. Java 21 apps targeting free Oracle support need to plan for Java 25 within the year. Java 17 apps have until 2029 — but that window is narrower than it sounds when you’re also running Java 8 and 11 migrations simultaneously.
3. Evaluate your OpenJDK vendor. If you need more time for Java 8 or 11 migrations, OpenJDK distributions — Eclipse Temurin, Amazon Corretto, Azul Zulu, Red Hat OpenJDK — provide extended community support. TuxCare’s Endless Lifecycle Support offers ongoing CVE patches for OpenJDK 8 and 11 past vendor EOL dates. These are delay tactics, not solutions — but they can buy 12-18 months of runway to execute migrations properly instead of in a panic.
Oracle Created This Problem
The shift to six-month feature releases starting with Java 10 was the right call for language velocity. It delivered records, sealed classes, virtual threads, and pattern matching faster than the old model ever could. But Oracle did not proportionally extend the free support windows on LTS versions to match the pace of release. The result: a language that is technically modern with a licensing and support model that is organizationally punishing.
Most enterprise Java shops have their upgrade strategy in a spreadsheet. That spreadsheet assumed staggered deadlines. If you haven’t updated it recently, it’s wrong. The first real deadline is September 2026 — and that is 90 days out.
