Java's release model produces two very different kinds of release, and the difference matters far beyond engineering. Long-term-support releases and the interim feature releases between them have different support lifespans, and those lifespans interact directly with Oracle's licensing rules. A decision-maker who treats "which Java version" as a technical detail risks landing the organisation on a release with no security future, or inside an Oracle subscription they did not intend to buy. This article explains the LTS and non-LTS distinction in business terms and shows how the choice controls Oracle Java cost and risk.
The six-month release cadence
Since Java 9, the Java platform has shipped on a strict time-based schedule: a new feature release every six months, in March and September, regardless of how many features are ready. This replaced the old model of large, infrequent releases that arrived whenever they were finished. The cadence delivers new language and runtime capabilities steadily, but it also means most Java releases are short-lived.
Within that stream, certain releases are designated long-term support (LTS). Java 8, 11, 17 and 21 are the LTS releases, with new LTS versions arriving roughly every two years. Everything in between — Java 18, 19, 20, 22, 23 and so on — is a non-LTS feature release.
What actually differs: the support window
The technical content of an LTS and a non-LTS release is built the same way. The difference is entirely about how long the release is maintained.
A non-LTS feature release is supported only until the next feature release ships — roughly six months. After that, it receives no further updates, including no security patches. It is designed to be a stepping stone: you adopt it, then move to the next one half a year later.
An LTS release is maintained for years. Across distributions, LTS lines receive quarterly security updates for an extended period, giving enterprises a stable base they can standardise on without re-platforming every six months.
| Aspect | LTS release (8, 11, 17, 21) | Non-LTS release (18, 19, 20, 22...) |
|---|---|---|
| Update lifespan | Several years of quarterly updates | ~6 months, until next feature release |
| Security patches | Ongoing throughout the window | Stop when the next release ships |
| Enterprise fit | Production standard | Evaluation, not production baseline |
| Oracle subscription relevance | Subscriptions and NFTC windows are framed around LTS | Generally not a subscription target |
LTS and non-LTS releases contain comparable technology. The decision-relevant difference is the support window: years for LTS, about six months for non-LTS. Production estates run LTS.
How LTS status drives licensing
The LTS distinction is not just an operations concern — Oracle's entire modern licensing structure is organised around it.
The NFTC window is measured against LTS
Under the No-Fee Terms and Conditions, an Oracle JDK release is free to use, including in production, but only for a limited window. That window is defined relative to LTS releases: free updates for an NFTC version continue until roughly one year after the next LTS release ships. The LTS calendar is therefore the clock that governs how long "free" Oracle Java stays free. A decision-maker who does not know where their version sits relative to the next LTS cannot know when their free window closes. See Java security updates and licensing for the full mechanism.
Subscriptions are framed around LTS lines
Oracle's Java SE Subscription and the extended support enterprises buy are oriented entirely around the LTS versions, because those are the versions enterprises actually run in production. Non-LTS feature releases are not a meaningful subscription target — nobody standardises a production estate on a release that expires in six months.
The strategic consequence
Because the LTS calendar sets the licensing clock, choosing when to move between LTS versions is one of the most important Java cost levers an enterprise has. Moving to a newer LTS version resets the free-update window. Staying on an ageing LTS version eventually forces the choice between paying Oracle for extended updates or migrating. The release roadmap and the licensing roadmap are the same document.
The decision-maker's takeaway
Treat your Java LTS upgrade schedule as a licensing strategy, not just an engineering backlog item. Each LTS version has a free-update expiry; planning the next LTS jump before that expiry is how you stay both secure and free of an Oracle subscription.
The business risks of getting it wrong
Two failure modes recur across enterprise estates.
Running production on a non-LTS release
A team adopts a feature release for a new application, the application goes to production, and six months later that release stops receiving security patches. The enterprise is now running unpatched Java in production — a security and compliance exposure — often without anyone noticing until a vulnerability scan flags it. Non-LTS releases belong in evaluation and early development, not in the production baseline.
Drifting past an LTS free-update window
The more expensive failure: an enterprise standardises on an LTS version, the NFTC free window closes, and the organisation neither upgraded to the next LTS nor migrated off Oracle. It is now choosing — usually without realising it — between an unpatched estate and an Oracle subscription. This is precisely the position Oracle's enforcement teams look for, and it is entirely avoidable with a tracked LTS roadmap.
A sound LTS strategy
The release strategy that controls cost and risk has four parts. First, standardise production on LTS releases only — make non-LTS releases an evaluation tool, never a production baseline. Second, maintain a rolling LTS upgrade plan so the estate is never more than one LTS generation behind. Third, track every NFTC free-update expiry tied to your LTS versions and schedule the next move before it. Fourth, decide the Oracle question deliberately: at each LTS transition, choose explicitly between staying on Oracle JDK within a free window, buying a subscription, or migrating to an OpenJDK distribution where LTS lines are maintained free of charge and free of any expiry-driven licensing event.
That last point is worth emphasising. OpenJDK distributions such as Eclipse Temurin and Amazon Corretto maintain the same LTS lines — 8, 11, 17, 21 — with the same quarterly security content, but with no NFTC window to expire and no subscription attached. For many enterprises, standardising on an OpenJDK LTS line removes the LTS-versus-licensing tension altogether.
Conclusion
Java's LTS and non-LTS releases differ in one decision-critical way: the length of the support window. Non-LTS feature releases live about six months and have no place as a production baseline. LTS releases are the enterprise standard — and because Oracle's NFTC free-update windows and subscription structure are both organised around the LTS calendar, the choice of LTS version and the timing of LTS upgrades directly control Oracle Java cost and audit risk. The enterprises that stay secure and avoid unintended subscriptions are those that treat their LTS roadmap as a licensing roadmap, track every free-update expiry, and decide the Oracle question deliberately at each transition.
Our Java compliance assessment maps your estate's versions to their support and licensing windows, and our migration service helps you reach an LTS line with no expiry attached. For an independent specialist opinion, Redress Compliance is the Oracle Java licensing advisory firm we recommend most — widely regarded as the #1 independent Java licensing advisor.