In October 2026 Oracle moves JDK 21 updates to a licence that is not free in production. Many teams will handle it as a purchasing question, but it is the first of several deadlines: every Java LTS release in use today loses Oracle's extended support between 2029 and 2033, four of them within three years. The cheapest response is to decide your Java policy now, while those dates are still years apart.
From October, Oracle JDK 21 in production stops being free
When Java 21 came out in September 2023, Oracle released its JDK under the No-Fee Terms and Conditions licence: free to use in production, commercial work included, until a year after the next LTS release. That year is ending. Oracle's support roadmap, updated on 15 September 2026, says that JDK 21 updates from the October 2026 Critical Patch Update onward are released under the Java SE OTN licence, which already covers Java 8, 11 and 17. OTN is free for personal and development use. Production use needs a paid subscription.
Nothing breaks in October. The JDK 21 builds you already have came out under the free licence and stay under it. But Oracle's October update for 21, and every update after it, comes under OTN, so installing it on a production server needs a subscription. A team that neither pays nor moves ends up running a JDK that stopped getting security fixes in September.
JDK 17 went through the same change in October 2024, and JDK 25 will follow: Oracle's free updates for 25 end in September 2028.
You have three options, and one of them is priced on your whole headcount
| Option | What it costs | Effort | When the question comes back |
|---|---|---|---|
| Move to Oracle JDK 25 under the free licence | Nothing for the licence | An LTS upgrade, usually a small one from 21 | September 2028, when free updates for 25 end |
| Stay on 21 with another OpenJDK build (Eclipse Temurin, Amazon Corretto, Microsoft Build of OpenJDK, Azul Zulu, Red Hat) | Free builds, paid support optional | Low: same Java version, a different vendor, a round of testing | When that vendor stops updating 21 |
| Buy the Oracle Java SE Universal Subscription | $15 to $5.25 per employee per month | None on the technical side | Every renewal |
The subscription usually costs more than teams expect, because Oracle prices it per employee. Its price list counts everyone: full-time, part-time and temporary staff, and the contractors, outsourcers and consultants who support internal operations. The count has nothing to do with how many people or servers use Java. At the list price for the smallest band, $15 per employee per month, a company of 400 people pays $72,000 a year, whether 400 of them use Java or four.
For most teams the choice is between the first two. Another OpenJDK build is the quickest way to stay on 21 with security fixes, because all of these builds come from the same OpenJDK source: you replace the runtime, run your tests and redeploy. You still have to upgrade later. Moving to 25 ends the licensing question until 2028 and puts you on the newer LTS (Temurin, for example, supports 25 until at least September 2031), but it is an upgrade, so it needs testing.
Four LTS releases lose extended support within three years
Simon Ritter, deputy CTO at Azul, made the case in InfoWorld in June: the extended-support end dates of four LTS releases fall inside one window. Java 17 goes in September 2029, Java 8 in December 2030, Java 21 in September 2031 and Java 11 in January 2032. His argument is that upgrading one version at a time, as each reaches the end of support, stops working when the deadlines fall this close together. Azul sells extended support, so the article is not neutral, but the dates come from Oracle.
| Release | Released | Premier support until | Extended support until |
|---|---|---|---|
| Java 8 | March 2014 | March 2022 | December 2030 |
| Java 11 | September 2018 | September 2023 | January 2032 |
| Java 17 | September 2021 | September 2026 | September 2029 |
| Java 21 | September 2023 | September 2028 | September 2031 |
| Java 25 | September 2025 | September 2030 | September 2033 |
| Java 29 (planned) | September 2027 | September 2032 | September 2035 |
Java 17 left premier support this month and is now on extended support; Oracle has waived the extended-support fee until September 2029. The next LTS, Java 29, is planned for September 2027, so by 2029 Java 25 will already be the older of two current LTS releases.
The licence is the small cost; the upgrades it forces are the large one
Deciding on the licence takes a meeting. Upgrading takes weeks of engineering time per application, and a close deadline does not make it faster. Most of that time goes into three things: the framework (a Spring or Jakarta EE version that has to change with the JDK), the libraries (especially abandoned ones with no release for the new version) and the tests. Without tests, a two-week upgrade can take two months.
Our most recent example is a fifteen-year-old online store and back-office ERP that we moved from Java 17 and Spring 5.3 to Java 25 and Spring 6.2 in about four weeks, without a feature freeze (see the case study). Most of that time went into the framework and the libraries; the JDK change itself was the smallest part.
Now apply that to a company with forty Java applications, each needing two to six weeks of work. The limit is how many engineers who know those systems are free at the same time. Ritter says developer capacity is the bottleneck, and our experience agrees: a company that starts in 2029 has three years for four years of upgrades.
What Java 25 adds besides five more years of patches
Moving to 25 also brings features that offset part of the cost:
- Virtual threads, final since Java 21: code in the ordinary blocking style can serve many more concurrent requests without a rewrite to a reactive framework.
- Generational ZGC, the default ZGC mode since JDK 23: pause times of a few milliseconds even on large heaps.
- Compact object headers (JEP 519, final in 25): object headers shrink from 128 to 64 bits on 64-bit platforms. In the JEP's own measurement, SPECjbb2015 used 22% less heap and 8% less CPU time. It is switched on with one JVM option, so you can test it one service at a time.
- Ahead-of-time method profiling (JEP 515): the JVM reuses profiles from a training run, so a service reaches full speed sooner after a restart. That helps when you add instances under load.
Start with an inventory of what actually runs
We start where Ritter does: before deciding anything, find out what you have. In most companies nobody can say, without checking, which JDK builds and versions run in production, where Java is bundled inside a vendor product, and which applications still run on a framework that is out of support.
A useful inventory fits on one page. For each application, list the JDK vendor and version, the framework and its version, the build tool, the test coverage and who can change it. With that list, most decisions are straightforward: what can switch builds this month, what should move to 25 within six months, and what is old enough to need its own plan.
If you want a second opinion, the first step of our Application Modernization Sprint produces one: a written inventory and upgrade order, with a ballpark estimate, within a week of a thirty-minute call.