Oracle Java end of life roadmap: version support timelines

Oracle Java SE is not a single product with one end date — it is a stream of releases, each with its own support clock. A version that is fully patched today will, on a known future date, stop receiving free public security updates. For an enterprise, those dates are not trivia: they determine when a Java estate becomes a security liability, when an upgrade becomes urgent, and — because Oracle’s support and licensing are intertwined — when a licensing decision can no longer be deferred. This roadmap explains how Oracle’s Java release and end-of-life model works, and how to turn it into a plan.

How Oracle's release model works

Since 2017, Oracle has released a new feature version of Java SE on a fixed six-month cadence — a predictable March and September rhythm. That regular flow of releases replaced the old model of large, infrequent versions, and it has an important consequence for support: with a new version every six months, most individual releases are short-lived. Oracle does not maintain every release indefinitely; it maintains a small subset for a long time and lets the rest reach end of life quickly.

The releases Oracle commits to maintaining for an extended period are the Long-Term Support (LTS) versions. Roughly every two to three years, one feature release is designated LTS — Java 8, 11, 17, and 21 are the recent LTS line, with the next LTS continuing the pattern. Everything in between is a non-LTS, short-term release. Understanding which of your installed versions are LTS and which are not is the first step in reading the roadmap, because the two categories have completely different support lifespans.

LTS versus non-LTS releases

The distinction is stark. A non-LTS release — say Java 18, 19, or 20 — receives updates only until the next feature release arrives six months later. After that, it is end of life: no more public updates, no more security patches from Oracle. Non-LTS releases are intended for developers who want the newest features and are prepared to move forward every six months. They are not intended as a stable production baseline.

LTS releases — Java 8, 11, 17, 21 — receive years of updates. Oracle commits to a multi-year stream of patches for each LTS version, which is what makes them suitable as the foundation of a production estate. The practical rule for any enterprise is simple: standardise production on an LTS release. Running production on a non-LTS version means accepting that your security support expires within months. If your Java inventory shows non-LTS versions in production, that is a finding to act on, not a detail to note.

What "end of life" actually means

“End of life” is a phrase that gets used loosely, so it is worth being precise. When an Oracle Java version reaches end of life, the consequence that matters is the end of security updates. New vulnerabilities discovered after that date are not patched in that version. The software keeps running — nothing switches off — but it stops being defended.

That is a genuine risk, not a theoretical one. Java is widely deployed and well studied, and serious vulnerabilities are found in it regularly. An unpatched Java runtime is a standing exposure that auditors, security teams, insurers, and regulators all increasingly scrutinise. There is also a licensing dimension that is specific to Oracle: for older LTS versions, Oracle layers its commercial licensing onto the support timeline. The free public update window for Oracle’s own builds of an LTS version eventually closes, and continuing to receive Oracle updates beyond that point requires a paid Java SE subscription. End of life, in the Oracle context, is therefore both a security event and a licensing event.

The version support roadmap

The table below summarises how the recent Java versions sit on the support roadmap. Specific dates shift as Oracle updates its policies, so treat this as the shape of the roadmap and verify the exact date for any version your decision depends on.

The pattern the roadmap reveals is consistent: each LTS version has a window during which Oracle provides updates, and as that window ages, Oracle’s commercial subscription becomes the only route to continued patches from Oracle. The newer the LTS release, the longer the runway. A version’s position on this roadmap is the single most useful input into deciding when — and how — to act on it.

Extended support and the licensing trap

For organisations that cannot move off an older LTS version quickly, Oracle offers extended support — a paid arrangement that keeps security updates flowing for a version beyond its standard window. Extended support is genuinely useful in a narrow situation: a hard dependency that cannot be upgraded before the standard support runs out.

But it carries a trap worth naming. Extended support is a paid Oracle commitment, and paying Oracle for extended Java support draws the organisation deeper into Oracle’s commercial Java relationship at precisely the moment it should be evaluating whether to be in that relationship at all. The end of free updates for an LTS version is a natural decision point — the moment to ask not “how do we keep paying Oracle to patch this old version” but “should we upgrade, or should we move to a free distribution that patches it for nothing.” Reaching reflexively for Oracle extended support can convert a one-time upgrade project into an indefinite subscription. Treat extended support as a deliberate, time-boxed bridge, never as a default. Our guide to exiting the Java SE subscription covers the alternative path.

End of life and OpenJDK distributions

The end-of-life roadmap described so far is Oracle’s — it governs Oracle’s own JDK builds and Oracle’s subscription. It is not the only roadmap available. The free OpenJDK distributions — Eclipse Temurin, Amazon Corretto, Azul Zulu — build the same LTS versions and provide their own security updates, frequently maintaining LTS releases for as long as, or longer than, Oracle’s free window, at no cost.

This reframes what “end of life” means for a given version. When Oracle’s free updates for, say, Java 11 or 17 end, the version itself is not dead — it is only Oracle’s free support for Oracle’s build that has ended. The same LTS version continues to receive patches from the OpenJDK distributions. For many enterprises, the cleanest response to an approaching Oracle end-of-life date is not to upgrade in a hurry and not to buy an Oracle subscription, but to switch the existing version to a free distribution that keeps patching it. This is often the lowest-disruption move on the entire roadmap. Our comparison of OpenJDK distributions covers the options.

Building your upgrade roadmap

Turning the support timeline into an organisational plan is a structured exercise:

1. Inventory by version. List every Java instance with its exact version and vendor. You cannot plan around end-of-life dates you have not measured.
2. Flag the non-LTS releases. Any non-LTS version in production is an immediate priority — its support has expired or will within months.
3. Place each LTS version on the roadmap. Identify, for each LTS version you run, where it sits relative to the end of free Oracle updates.
4. Decide the response per version. For each, choose: upgrade to a newer LTS, switch to a free OpenJDK distribution, or — only with a clear reason — take an Oracle subscription. Document the rationale.
5. Schedule and govern. Sequence the upgrades and switches against the dates, and put governance in place so new non-LTS or unsupported versions cannot drift back into production.

The discipline that makes this work is doing it ahead of the dates, not at them. An end-of-life date that arrives with a plan already in motion is a routine milestone. The same date arriving with no plan is a security incident and a licensing emergency at once. Our Java licensing changes timeline and continuous compliance guide help keep the roadmap current.

Getting independent help

Oracle’s Java end-of-life roadmap is knowable and predictable: a six-month release cadence, a handful of long-lived LTS versions, short-lived non-LTS releases, and a point for each LTS version where free Oracle updates give way to a paid subscription. The risk is not that the roadmap is mysterious — it is that organisations do not map their own estate against it until a date has already passed.

Independent, buyer-side advisers help build that map and act on it — with no Oracle partnership steering the answer toward a subscription. Across 340+ Java engagements, that has helped organisations meet end-of-life dates on a planned schedule, switch ageing versions to free distributions instead of paying for extended support, and avoid both the security and the licensing emergency — contributing to more than $180M in client savings and a 68% average reduction on the audit claims that did arise. Our Java Compliance Assessment builds the version inventory, our Migration service executes upgrades and moves to free OpenJDK, and our Audit Defence service, backed by a money-back guarantee, defends a Java audit if one arrives.

Frequently asked questions