Long term support decides how often you must move and how long you get free security updates, and it varies widely across distributions. Standardize on a long term support release with a long free window, and treat extended paid support as an exception for workloads you cannot move in time.
Java ships a new feature release every six months, but only certain releases are designated long term support, which is where enterprises live. The recent long term support releases are Java 8, 11, 17, and 21. A long term support release receives security and stability updates for years rather than months, which is what lets you standardize and stay put without chasing a new version twice a year. Choosing a distribution is, in large part, choosing how long that update stream stays free.
This is where buyers get surprised. Two distributions can both call a release long term support and still promise very different free update windows for it. Some vendors commit to long multi year windows on the major long term support releases at no charge. Others patch the newest long term support releases for free but stop sooner on the older ones, pushing you toward a paid agreement if you stay on a legacy version. The release number alone does not tell you how long you are covered. The distribution's published policy does.
| Release | Status | Question for the buyer |
|---|---|---|
| Java 8 | Oldest common long term support | Who still patches it for free, and for how long? |
| Java 11 | Widely deployed long term support | Is the free window still open on my build? |
| Java 17 | Current mainstream long term support | How many years of free updates remain? |
| Java 21 | Newest long term support | The longest runway, best for new standardization |
Treat the table as a prompt, not a promise. The exact dates depend on the distribution you pick, so confirm them against the vendor's current policy before you commit.
The cleanest position is to standardize on a newer long term support release, such as Java 17 or 21, where the free window is longest. That buys you the most years before you must move again, and it keeps the runtime cost at zero across the bulk of the estate. Moving forward a release is testing work, not rewriting work, because the source base is shared. Our guide to how to choose a Java distribution covers how support window sits alongside the other criteria.
Some workloads cannot move in time. A legacy application certified only on an older release, or a system frozen for a regulatory reason, may need patches after the free window closes. That is a legitimate case for a paid extended support agreement, scoped to those named workloads only. The discipline is the same as everywhere else: attach the cost to the workload that needs it, never to the whole estate. We draw that line in our look at free versus paid OpenJDK distributions.
Long term support release plus distribution policy decides your free update runway. Standardize on a newer long term support release for the longest free window, confirm the exact dates with the vendor, and pay for extended support only on the workloads you genuinely cannot move yet.
A long free support window is what lets you leave the Oracle Java subscription and stay left. For the licensing context and the per employee numbers, read our Oracle Java licensing guide for 2026.
Book a Strategy Call and we will check the free update window on every release in your estate and flag where extended support is the only honest answer.
Book a Strategy Call Download the guideFixed fee or gainshare, both backed by our guarantee. We sit between you and Oracle and we never take vendor money.
Get a QuoteWeekly intelligence on Oracle Java licensing moves and the buyer side defenses that work.