Java Support Deadlines and the Oracle Licensing Trap: What Actually Runs Out, and When
Most software has one countdown: the day security patches stop. Java running on Oracle's JDK has two — a support clock and a licensing clock — and teams that plan around only one of them routinely get caught by the other. This guide lays out both, with every support date verified against vendor lifecycle data, and the escape path that resolves the two problems at once.
The support clock: which Java versions are still patched
Java ships on a release train: a new version every six months, with certain releases designated long-term support (LTS) — 8, 11, 17, 21, and 25. Almost all production Java in the world sits on an LTS. Here is where each one stands:
| Version | Oracle JDK support ends | Eclipse Temurin (OpenJDK) support ends | Status |
|---|---|---|---|
| Java 8 | March 31, 2022 | December 31, 2030 | Oracle EOL |
| Java 11 | September 30, 2023 | October 31, 2027 | Oracle EOL |
| Java 17 | September 30, 2026 | October 31, 2027 | Ends this quarter |
| Java 21 | September 30, 2028 | December 31, 2029 | Supported |
| Java 25 | September 30, 2030 | — | Supported |
Read that table twice, because the pattern is the story: the free, open-source builds of Java outlive Oracle's own JDK support on every legacy LTS. Temurin 8 will still be receiving community security patches more than eight years after Oracle JDK 8 support ended. Which build of Java you run has become a bigger deal than which version.
The licensing clock: how "free Java" quietly became a subscription
The licensing side is what turns a stale runtime into a budget problem. In broad, uncontested strokes:
2019: Oracle ended free public updates of Oracle JDK 8 for commercial use. From that point, applying JDK 8 patches in a business environment generally required a paid Java SE subscription. Enormous numbers of installs kept updating anyway — many organizations simply didn't notice the terms had changed.
2021: With JDK 17, Oracle introduced the "No-Fee Terms and Conditions" (NFTC) license — Oracle JDK free again, including commercial use, but only for a window: roughly until a year after the next LTS ships. When that window closes, continued updates fall back under paid terms. Free, with an expiry date most calendars never captured.
2023: Oracle moved new subscriptions to the Java SE Universal Subscription, priced per employee — not per server, not per developer, but across an organization's entire headcount, regardless of how many actually touch Java. For a company with a handful of Java services and thousands of employees, the quote change was dramatic, and it made "a few old JDK installs somewhere" a company-wide licensing question. Oracle's terms have changed several times and can change again — verify the current terms directly before making decisions that depend on them.
The escape path: same Java, different build
What saves most teams is a fact that still surprises people: since Java 11, Oracle JDK and OpenJDK are built from essentially the same source code. The class files your application runs are the same platform. That means the fix is rarely "rewrite the app" — it's "swap the runtime":
1. Move to an OpenJDK build (most teams' answer)
Eclipse Temurin (from the Adoptium project) is the most widely adopted open-source build — no license fee, no audit surface, passes the same compatibility test suite. Swap the runtime, run your test suite, done. Other freely available OpenJDK builds exist as well, including Oracle's own no-cost OpenJDK builds — though those only receive updates for six months per release, so they suit teams that upgrade continuously, not teams that sit on an LTS.
2. Upgrade the version while you're at it
If you're touching the runtime anyway, land on Java 21 rather than 17 — 17's Oracle support ends this September, and even Temurin 17 runs out in October 2027. The 8-to-modern jump is the only genuinely hard one (removed internal APIs, module system); 11-to-21 and 17-to-21 are usually routine.
3. Can't move yet? Bridge it — deliberately
Some Java 8 estates are welded to vendor software that will never certify a newer runtime. For those, commercial extended-support vendors provide continued security patches for legacy Java versions — see our extended support options page. Treat it as a bridge with a migration date attached, not a destination.
What to do this quarter
Inventory first: find every JVM in the estate and identify its build (Oracle JDK vs an OpenJDK distribution) and version — java -version tells you both. Anything on Oracle JDK 8 or 11 is the priority pile: it's years unpatched and carries the licensing exposure. Anything on Oracle JDK 17 has a hard date — September 30, 2026 — to either subscribe, swap builds, or upgrade. You can check any version's current status in seconds with the EOL checker, and the rest of 2026's deadline calendar — OpenSSL 3.0, Python 3.10, .NET 8/9, PostgreSQL 14, PHP 8.2 — lives on the EOL Watch page.
Frequently Asked Questions
When does Oracle JDK 17 reach end of life?
Oracle JDK 17 support ends September 30, 2026. Oracle JDK 8 ended March 31, 2022, and JDK 11 ended September 30, 2023. Oracle JDK 21 runs to September 30, 2028; JDK 25 to September 30, 2030.
Is OpenJDK really a drop-in replacement for Oracle JDK?
For the vast majority of workloads, yes. Since Java 11 they're built from essentially the same source, and vendor builds like Eclipse Temurin pass the same compatibility test suite. Most migrations are a runtime swap plus a test run.
Does OpenJDK get security updates longer than Oracle JDK?
Often, yes. Temurin 8 is supported to December 31, 2030 — over eight years past Oracle JDK 8's end of support. Temurin 11 and 17 run to October 31, 2027; Temurin 21 to December 31, 2029.
Why do old Oracle JDK installs create licensing risk?
Since 2019, applying Oracle JDK 8 updates commercially has generally required a paid subscription, and Oracle's current Java SE Universal Subscription is priced per employee organization-wide. Unlicensed installs that received updates are a common audit finding. Terms change — verify Oracle's current terms directly.