The JDK Release Cadence Turns 10: Did Six-Month Releases Actually Speed Up Java?

Cast your mind back to September 2017. Mark Reinhold, chief architect of the Java Platform Group at Oracle, posted a short but consequential proposal: instead of waiting years between major Java releases, the JDK would ship a new version every six months, like clockwork, every March and September. No more holding the whole train for a single stalled feature. If a feature missed the window, it would simply catch the next one.

The community was skeptical, frankly. At the time, Java 9 had already slipped its original schedule more than once due to the complexity of Project Jigsaw (the module system). But Reinhold’s argument was simple: the old model — where a “major version” meant dozens of massive spec-changing features bundled together — was causing exactly those delays. Smaller, faster, more frequent was the answer.

As of March 2026, we have now seen 17 full releases under that model, from Java 10 through Java 26. That is enough history to evaluate honestly whether the promise held up — and where it fell short.

1. First, a Quick Look at Where We Came From

Before we can judge the new cadence fairly, it helps to remember just how slow things used to be. Java 6 arrived in 2006. Java 7 did not land until 2011 — a five-year gap. Java 8 followed in 2014. Java 9, which was originally targeted for 2016, finally shipped in September 2017 after Project Jigsaw’s acceptance debates dragged on. Meanwhile, Python, Node.js, and Go were shipping major improvements on yearly or even sub-yearly timelines. The community joke was that Java was moving so slowly it was practically geological.

“The pace of innovation is happening at an ever-increasing rate and this new release model will allow developers to leverage new features in production as soon as possible.”— Sharat Chander, Oracle Java SE Product Management Director, March 2018

Consequently, the release of Java 10 in March 2018 — exactly six months after Java 9 — was genuinely striking. It arrived on schedule, it included twelve JEPs (JDK Enhancement Proposals), and it proved that the machinery worked. That said, not everything changed overnight. And understanding both the wins and the compromises is where the real story lives.

2. What Genuinely Got Better

Features Stopped Holding Each Other Hostage

Under the old model, one delayed feature could derail an entire release. Project Jigsaw caused Java 9 to slip roughly a year. Under the new cadence, a feature that is not ready simply ships in the next release, six months later. This sounds trivial, but it is one of the most structurally important changes in Java’s history. Teams working on preview features — for example, record patterns, pattern matching for switch, and eventually virtual threads — could iterate in public across multiple releases, collect real developer feedback, and stabilize properly before a final LTS locked them in.

The Preview System: A Genuine Innovation

Possibly the most underrated benefit of the new cadence is the formal preview feature system introduced alongside it. Under JEP 12, a feature can ship as “preview” — fully implemented, but not yet final — and then be refined or even withdrawn based on community response. Text blocks, for instance, previewed in Java 13 and Java 14 before finalizing in Java 15. Virtual threads previewed in Java 19 and 20, then became a permanent feature in Java 21. This iterative public feedback loop simply did not exist before 2018.

Tool Vendors Finally Had a Predictable Schedule

Oracle noted early on that one unexpected benefit was how other projects responded. When Java 10 launched, major IDEs — IntelliJ IDEA, Eclipse, and NetBeans — all had support within days. Gradle and Apache Lucene quickly added official support. A predictable March/September window gave third-party tool maintainers enough runway to be ready at launch, rather than scrambling reactively.

JEPs Delivered Per Java Release (Java 8 → Java 26)

As the chart above shows, the JEP count per release has been remarkably consistent since Java 10, typically hovering between 8 and 21, with LTS releases tending to land slightly higher (Java 21 delivered 15, and Java 25 delivered 18). This consistency is itself meaningful — it signals that the engineering pipeline is flowing steadily rather than in the feast-or-famine cycles of the pre-2018 era.

3. The Releases at a Glance

Below is a concise reference table covering every release in the six-month era, including its release month and notable landmark features. LTS releases are separately marked, since they matter most for enterprise adoption.

4. The Honest Critique: What the New Cadence Did Not Solve

Enterprises Largely Ignored Non-LTS Releases

Here is where the promise and the reality diverge. The six-month cadence was genuinely exciting for individual developers and framework teams. But most production-grade enterprise applications never upgraded to Java 12, 13, 14, 15, 16, 18, 19, 20, 22, 23, 24, or 26. They jumped from LTS to LTS. According to New Relic’s 2024 State of the Java Ecosystem report, a staggering two-thirds of respondents were still running Java 11 or earlier at the time of the survey. Separately, Azul’s 2025 State of Java Survey found that 19% of participants were still running Java 6 or 7 in production — versions released in 2006 and 2011 respectively.

Τhe Adoption Reality

According to multiple 2024–2025 surveys, 29–50% of developers still use Java 8 in at least some production applications. The six-month cadence accelerated feature delivery but has not accelerated enterprise upgrade cycles.

The Two-Speed Java Problem

What effectively emerged is a two-speed Java: a fast lane for startups, framework authors, and developers who enjoy living closer to the edge, and a slow lane where the majority of enterprise Java actually lives. JRebel’s 2024 Java Developer Productivity Report found that LTS support (25%) and security (24%) — not new features — were the top reasons enterprises cited for upgrading. New features came in at only 19%. The implication is clear: most organizations upgrade because they have to, not because they are excited about switch expressions.

Upgrade Fatigue, Licensing Noise, and Oracle’s Pricing Changes

The cadence argument was further complicated by Oracle’s 2023 commercial licensing shift, which changed Oracle JDK pricing from per-processor to per-employee, dramatically increasing costs for many organizations. As a result, InfoQ’s 2024 Java Trends Report noted that over 70% of respondents were considering non-Oracle JDK alternatives. The release cadence itself became entangled in a licensing debate that had nothing to do with engineering. Oracle’s market share fell from 75% in 2020 to just 21% by 2024, as developers migrated to Eclipse Adoptium, Amazon Corretto, and Azul Zulu.

Java Version Adoption in Production (2024–2025)

5. Three Features the Cadence Made Possible

To understand why the six-month model was still the right call despite the adoption lag, it helps to trace three specific features that could only have been built the way they were because the cadence allowed incremental, public iteration.

Records — Preview to Final in 2 Releases (Java 14 → 16)

Records shipped as a preview in Java 14 (March 2020), refined after feedback in Java 15, and became final in Java 16 (March 2021). Under the old model, they would have waited for a big-bang LTS bundling. Instead, developers tested and influenced the final API in real projects for a full year before it locked in.

Virtual Threads — 3 Years of Incubation (Java 19 → 21)

One of the most impactful JVM changes in decades, virtual threads from Project Loom previewed in Java 19 (September 2022) and Java 20 before landing as a final feature in Java 21 (September 2023). Frameworks like Spring Boot had time to adapt and test before the feature became permanent.

Pattern Matching for Switch — 4 Previews (Java 17 → 21)

Pattern matching for switch previewed across four consecutive releases before finalizing in Java 21. Each iteration addressed edge cases and semantic questions raised by the community. The result was a cleaner, more correct final API than could have been designed without public testing.

Project Leyden (AOT) — Begins Landing in Java 24–26

Project Leyden’s ahead-of-time compilation work began arriving in Java 24 with AOT class loading, expanded in Java 25 with method profiling, and continues in Java 26. Without the cadence, all of this would have had to ship as one enormous, risky feature drop instead of composable, incremental pieces.

6. One More Improvement: The LTS Window Shortened Too

It is worth noting that the community’s own feedback about adoption shaped an adjustment to the original plan. When the new cadence launched, LTS releases were supposed to come every three years. However, Oracle and the broader OpenJDK community recognized that three years was too long for enterprise upgrade cycles. Starting with Java 17, the LTS cadence shifted to every two years. That means the gap between stable, long-supported targets went from three years (or longer, in the old world) down to two. Meanwhile, non-LTS releases handle the experimentation in between. This two-tier architecture is arguably the most important structural design in modern Java.

The Two-Tier Model That Emerged

Fast lane (every 6 months): feature releases with previews and incubators — for developers who want to stay current.

Slow lane (every 2 years): LTS releases — stable, long-supported targets for enterprises who prioritize reliability over novelty. Both lanes move faster than they ever did pre-2018.

Furthermore, adoption of each LTS is now happening considerably faster than it used to. New Relic’s data showed Java 21 was adopted by 1.4% of monitored applications within its first six months — nearly four times the 0.37% adoption rate Java 17 had at the same post-release milestone. Meanwhile, by 2025, Java 17 had reached 61% of enterprise developers, and Java 21 was already at 45%. Those are not the numbers of an ecosystem frozen in place.

7. Quickly Check What You Are Running

If you are curious about your own Java version right now, the following commands work on any operating system. No special tools required — just open a terminal or command prompt.

Check your installed Java version (Linux, macOS, or Windows Command Prompt / PowerShell):

java -version

The output will look something like this on a modern machine:

openjdk version "21.0.3" 2024-04-16
OpenJDK Runtime Environment (build 21.0.3+9)
OpenJDK 64-Bit Server VM (build 21.0.3+9, mixed mode, sharing)

The first line tells you the version number (here, Java 21) and the build date. If you see Java 8 or Java 11 in production and your organization has not started planning the upgrade, you are now behind on at least one LTS cycle. Both Java 11’s free Oracle support and Java 17’s free Oracle commercial support have already ended.

Which version should you target?

For new projects starting today (March 2026): Java 21 is the safe, battle-tested LTS choice with virtual threads and modern pattern matching. Java 25, released September 2025, is the newest LTS — consider it if you are greenfield and want the latest stable baseline. Avoid non-LTS versions for long-lived production systems.

8. What We Have Learned

Ten years into the six-month release cadence — and eight years after Java 10 formally kicked it off — the honest verdict is this: the cadence did speed up Java, but not in the way most people expected.

It did not cause enterprises to upgrade faster. Most production systems still follow the LTS rhythm, and plenty of them are still years behind even that. However, what the cadence genuinely transformed is the quality and transparency of feature development. The preview system gave Java something it had never had before: a mechanism for shipping real, usable implementations for community feedback before they become permanent. Records, virtual threads, and pattern matching all benefited enormously from this, arriving in their final form as considerably better APIs than they would have been under a big-bang release.

Furthermore, the pressure of a fixed release window forced more disciplined, composable engineering. Features had to be scoped to fit six months or clearly marked as multi-cycle work. Projects like Loom, Valhalla, and Leyden learned to deliver incremental value across releases rather than landing as single seismic events. And tool vendors — IDEs, build tools, frameworks — finally had predictability they could plan around.

The two-tier LTS model that emerged, with stable targets every two years and experimentation every six months, is arguably the best design the Java community could have landed on given the breadth of its user base. Startups and framework builders live in the fast lane; enterprises live in the slow lane. Both, however, are moving faster than before 2018. That is the genuine achievement of the last ten years.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

and many more ....

I agree to the Terms and Privacy Policy

Sign up

Thank you!

We will contact you soon.