The LTS clock does not pause for a busy quarter

OpenJDK runs on a six-month release cadence with a long-term support release every two years, and every production Java estate must hold an LTS runway long enough to plan the next transition without panic. LTS releases get five-plus years of upstream community support, most distributions extend paid support to seven to ten years, and non-LTS releases are for development only. The roadmap covers the LTS cadence, the current support windows, and the next transitions.

Prepared by Redress Compliance · August 9, 2026 · Oracle Java advisory. Based on the OpenJDK LTS timelines and the migration engagement file.

• Java 11 to Java 17: most Java 11 estates moved in 2023 and 2024, and Java 11 community support ends September 2026 across most distributions, so any remaining Java 11 in production is now on borrowed time.
• Java 17 to Java 21: the current transition window, planned in 2026 to 2027 ahead of Java 17 distribution EOL, which runs October 2027 to January 2030 depending on the distribution.
• Java 21 to Java 25: the window opens in 2026 and runs through 2028, with Java 25 having landed September 2025 as the next production target.
• Standardise and simplify: standardise on LTS releases and deprecate any production non-LTS, and pick one or two primary distributions, because multiple distributions add support complexity without material engineering benefit.
• Runway is the protection: maintain at least eighteen months of support runway on every production LTS and build the next transition plan at LTS plus eighteen months, because late plans force emergency migrations that cost more than scheduled ones.

The upstream OpenJDK community provides updates for around five years from the initial LTS release, carrying the same code quality as the original with all security patches, bug fixes and CVE responses, and distribution vendors extend beyond that timeline.

So the distribution choice sets the real support horizon.

Pick one or two primary distributions aligned to the dominant cloud or operating system in the estate: Microsoft Build of OpenJDK suits Azure-heavy estates, Amazon Corretto suits AWS-heavy estates.

And Eclipse Temurin suits cloud-agnostic estates, because running multiple distributions adds support complexity without material engineering benefit.

Then hold the runway: maintain at least eighteen months of support runway on every LTS in production to protect against unexpected migration disruption.

And build the next transition plan at LTS plus eighteen months, because late transition plans force emergency migrations that cost more than scheduled ones.

Every Java estate runs three or four distributions, each with its own end-of-life clock, so the roadmap is the only way to keep production aligned with support.

This roadmap applies to Oracle Java SE customers too for the LTS cadence, because Oracle Java SE follows the same LTS version numbers and release dates as OpenJDK.

The licensing model differs but the technical roadmap is the same, which is why the distribution and runway discipline is the foundation of any Java cost and migration decision. The Oracle Java licensing and audit posture sits in the Oracle Java pillar.

Four moves recur in every well-managed Java estate, and the discipline is a scheduled cadence rather than a reaction to an end-of-life date, because the LTS clock does not pause for a busy quarter:

Move one is LTS standardisation: standardise on LTS releases and deprecate any production non-LTS deployments, because the LTS commitment simplifies the support and migration cadence.

Move two is distribution choice: pick one or two primary OpenJDK distributions, because multiple distributions add support complexity without material engineering benefit.

Move three is build runway: maintain at least eighteen months of support runway on every LTS in production, because the runway protects against unexpected migration disruption.

Move four is plan the next transition: build the next transition plan at LTS plus eighteen months, because late transition plans force emergency migrations that cost more than scheduled ones.

The sequence is to map every Java instance to its current LTS version and distribution, identify and deprecate any non-LTS deployments in production, standardise on one or two primary distributions, build the support runway forecast per LTS for the next thirty-six months.

Plan the Java 17 to Java 21 transition window, plan the Java 21 to Java 25 window, lock developer tooling to the chosen distribution and LTS, and engage independent Oracle Java advisory on the migration plan.

The wider Oracle Java library sits in the Oracle practice.

What is the OpenJDK LTS cadence?

OpenJDK ships a new LTS release every two years, on a six-month overall release cadence where the non-LTS releases in between are for development and testing only. The current LTS releases are Java 11, Java 17 and Java 21, with Java 25 LTS releasing in September 2025 as the next production target.

Two or three LTS versions are active at any time, which is why most enterprises run two or three in production and manage transitions on a scheduled cadence.

How long does each OpenJDK LTS get supported?

Community support runs for around five years from the initial LTS release, carrying the same code quality as the original with security patches, bug fixes and CVE responses.

Distribution vendors extend support to seven to ten years through paid and free community channels, so the distribution choice sets the real support horizon.

For example Microsoft Build of OpenJDK supports Java 21 through September 2031 free for commercial use, and Azul Platform Prime adds four years beyond the community window.

Should we ever run non-LTS OpenJDK releases in production?

No. Non-LTS releases ship every six months and lose support quickly, so they belong in development and testing only.

Production deployments should run on LTS releases exclusively, because the LTS commitment gives the five-plus years of community support and the seven-to-ten-year distribution extension that a stable estate needs.

Deprecating any production non-LTS deployments is the first of the four buyer-side moves on the roadmap.

Which OpenJDK distribution should we standardise on?

Pick one or two primary distributions aligned to the dominant cloud or operating system in the estate: Microsoft Build of OpenJDK suits Azure-heavy estates, Amazon Corretto suits AWS-heavy estates, and Eclipse Temurin suits cloud-agnostic estates.

Running multiple distributions adds support complexity without material engineering benefit, and each distribution carries its own end-of-life clock, so consolidating to one or two keeps the roadmap manageable and production aligned with support.

When should we move from Java 17 to Java 21?

Plan the transition window from 2026 through 2027, ahead of Java 17 distribution EOL, which runs from October 2027 to as late as January 2030 depending on the distribution.

Build a clear runway plan with at least eighteen months of buffer, because late transition plans force emergency migrations that cost more than scheduled ones. The Java 21 to Java 25 window opens in 2026 and runs through 2028, so many estates will be planning both transitions in parallel.

Does the OpenJDK roadmap apply to Oracle Java SE customers?

Yes for the LTS cadence. Oracle Java SE follows the same LTS version numbers and release dates as OpenJDK, so the technical roadmap, the LTS releases, the transition windows and the runway discipline, is identical.

The licensing model differs, because Oracle Java SE is a paid per-employee subscription while OpenJDK distributions are free or separately supported, but the version and end-of-life planning is the same, which is why the roadmap underpins any Oracle Java cost decision.