Azul deputy CTO Simon Ritter warns that enterprise Java teams are sleepwalking towards a support cliff.

Ritter, who joined Sun Microsystems in 1996 and now works at Azul, says four long-term support versions of Java will reach end-of-support between 2029 and 2032. Java 17 goes first in 2029, followed by Java 8 in 2030, Java 21 in 2031 and Java 11 in 2032.

Writing in Infoworld, Ritter said: “Between 2029 and 2032, every currently supported long-term support (LTS) version of Java will reach end-of-support within a single three-year window.”

On paper, this looks like a neat upgrade cycle, but Ritter says the reality is a nasty collision of timelines that most enterprises have failed to forecast. Organisations still planning to modernise slowly, moving application by application and version by version, are working from a model the calendar has already mugged.

“The primary danger here is the illusion of time,” Ritter said.

Traditional modernisation plans rely on sequential upgrades and controlled pacing. Ritter argues that once every major Java version expires in the same cramped window, sequential planning collapses.

By the time that becomes obvious, companies will be forced into reactive mode. That means rushed decisions, emergency projects and the usual corporate theatre with extra Jira tickets.

For organisations planning the familiar Java 8 to Java 11 to Java 17 to Java 21 slog, a maintenance task becomes a structural problem. Enterprises with large Java estates will need to upgrade multiple applications across multiple versions simultaneously. That is needed to maintain security compliance and business continuity.

“Waiting until the late 2020s to act guarantees a modernisation process under emergency conditions,” Ritter said.

Modern Java versions still have strong backwards compatibility, but Ritter says that will not offset decades of technical debt.

Large Java environments are stuffed with unused libraries, obsolete logic, forgotten dependencies and dormant features. Much of this stuff no longer runs in production, but it still eats developer time and security oversight.

As codebases age, the drag compounds. What looks like a tidy version upgrade on a roadmap turns into a sprawling operational headache.

Ritter says most modernisation strategies assume upgrades can be sequenced and absorbed gradually. That assumption is now dangerous.

“When multiple Java versions reach end-of-support in the same narrow window, enterprises don’t face a single modernisation project; they face parallel modernisation across their entire estate,” Ritter wrote.

That moves the problem away from frameworks and into people. A typical enterprise with 100 developers cannot afford to waste chunks of its capacity maintaining dead code that delivers no business value.

Multiply that across dozens or hundreds of applications, and the bottleneck becomes obvious. Modernisation is limited by people, not magic tools. Parallel modernisation needs parallel capacity, and most organisations have not budgeted for it, he said.

Ritter says tools that analyse code in isolation cannot tell what matters in production. Without that visibility, companies default to caution and turn their timelines into risk.

“The Java modernisation crunch is a crisis of resource allocation, not a technology problem,” Ritter said.

Every hour spent maintaining obsolete code or investigating unused dependencies is an hour stolen from modernisation. When organisations face simultaneous upgrades across multiple applications, human capacity becomes the hard limit. Sequential planning needs time, while parallel modernisation needs people. Most enterprises no longer have enough of either.

Those tackling technical debt now will still have a difficult transition, but at least it will be manageable. Those who do not will face rushed choices and permanent compromises.

“By the time 2029 arrives, the window for gradual modernisation will have closed. The calendar won’t wait for us to be ready,” Ritter said.