Four LTS Java Versions Get End-of-Support in a Three-Year Window (2029-2032)

Four LTS Java Versions Get End-of-Support in a Three-Year Window (2029-2032) (infoworld.com) 26 Simon Ritter joined Sun Microsystems in 1996 and spent time working in both Java development and consultancy. He's now written an opinion piece for InfoWorld warning that "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." That's Java 17 in 2029, Java 8 in 2030, Java 21 in 2031, and Java 11 in 2032... On paper, this looks like a manageable upgrade cycle. In practice, it creates a collision of timelines that most enterprises have failed to forecast. Organizations attempting to modernize incrementally — moving application by application, version by version — are operating on a model that the calendar has already rendered obsolete... [W]hen every major Java version expires in the same compressed window, sequential planning collapses. By the time this becomes obvious, organizations will be forced into reactive mode, making rushed decisions under extreme pressure. For organizations planning traditional stepwise upgrades — Java 8 to Java 11 to Java 17 to Java 21 — this convergence elevates a routine maintenance task into a structural crisis. Enterprises with large Java estates will be forced to upgrade multiple applications across multiple versions simultaneously to maintain security compliance and business continuity. "Parallel modernization requires parallel capacity — something most organizations haven't budgeted for," he points out. "This explains why traditional approaches struggle to scale." That's Java 17 in 2029, Java 8 in 2030, Java 21 in 2031, and Java 11 in 2032... On paper, this looks like a manageable upgrade cycle. In practice, it creates a collision of timelines that most enterprises have failed to forecast. Organizations attempting to modernize incrementally — moving application by application, version by version — are operating on a model that the calendar has already rendered obsolete... [W]hen every major Java version expires in the same compressed window, sequential planning collapses. By the time this becomes obvious, organizations will be forced into reactive mode, making rushed decisions under extreme pressure. For organizations planning traditional stepwise upgrades — Java 8 to Java 11 to Java 17 to Java 21 — this convergence elevates a routine maintenance task into a structural crisis. Enterprises with large Java estates will be forced to upgrade multiple applications across multiple versions simultaneously to maintain security compliance and business continuity. "Parallel modernization requires parallel capacity — something most organizations haven't budgeted for," he points out. "This explains why traditional approaches struggle to scale." I'm wetting my pants now (Score:1) Re: (Score:1) You'll be pleased to know then that the only remaining LTS option, Java 25, will itself be exiting extended support in 2033 and there's nothing in the roadmap yet to replace it. Java 29 (September 2027) is on the roadmap as the next LTS after Java 25: https://ops.java/releases/ [ops.java] Re: (Score:2) Moving off a platform that auto-expires constantly in order to force you to migrate to a newer ($$$) platform that will also auto-expire shortly after you move to it does seem to be a good idea. For reference, we recently declared VC++ 6.0, from 1998, unsupported, not because there's a problem with it but because getting it to run under the latest Win11 is too hard. Having said that, binaries built using VC++ 6.0 still run fine under the latest Win11, and that's a nearly 30-year-old dev.system which, admit Re:I'm wetting my pants now (Score:4, Insightful) Money. It costs money to hire a developer, understand what needs to be done, etc. Many of these projects probably haven't had a developer look at them in 10 years. Also, inevitably a developer assigned to upgrade such a project will say "we need to upgrade library X, Y, Z"... adding to the costs and the risks of regression. Maybe there are security risks, but many of these programs are also on private networks, reducing (not eliminating, of course) the potential for exploitation. You don't fix what isn't broken. Re: I'm wetting my pants now (Score:1) Re: (Score:2) It's not just your company, I've come across it many places. Why are so many enterprises still on Java 8? Those same companies were on Java 5 for like 25 years before they "upgraded" to Java 8. 100% guaranteed they will "upgrade" to 17 instead of whatever version is current. You realize there are people who weren't born when Java 8 came out in like what 2012 or something? Jesus Christ. (Note, Christ himself may have still been around.) Re: (Score:2) Re: (Score:1) We are still on Java8 with our entreprise software That's not necessarily a problem. Java 8 is still a supported LTS version for most Java distributions. For Azul Zulu for instance, support for Java 17 ends earlier (September 2029) than for Java 8 (December 2030): https://www.azul.com/products/... [azul.com] Just move away from Java 8 in time. When 'in time' is depends on the complexity of your use case. Upgrading multiple Java versions at once is easy (Score:1) Re:Upgrading multiple Java versions at once is eas (Score:5, Informative) Not true anymore, this was very through from java 1 to java 8 although. and most existing Java 8 code would continue to work unchanged in Java 25. No, you will almost need refactoring in 95% of cases. I spent quite a bit of time on that. Sun stopped supporting and providing the javax.* packages and they've been replaced by the jakarta.* packages. Java finally started to remove deprecated packages, classes and methods after java 8 so refactoring is not only a matter of renaming the imports. You will also need to upgrade most of the external libraries you use for that reason and they have their own specific changes too. Re: (Score:3) Those javax -> jakarta packages were not part of the JRE. However, those common interfaces are extremely popular. So you probably use a framework or library which uses them and has transitioned to the newer packages. But you could still use the old frameworks or libraries in a newer JRE, assuming they do not use a library that messes with JVM bytecode (which is commonly used to create more advanced class proxies). Javaassist, OW2 ASM, and the likes are the problematic parts for moving on to a newer JRE. Re: (Score:2) Those javax -> jakarta packages were not part of the JRE. However, those common interfaces are extremely popular. True but running anything with an http interface will almost always use the javax.http.servlet package for example. Just for fun, here is a challenge, find me a java 8 enterprise application which doesn't use at least one of these package: javax.accessibility Defines a contract between user-interface components and an assistive technology that provides access to those components. javax.activation javax.activity Contains Activity service related exceptions thrown by the ORB machinery during unmarshalling. javax.ann Capitalism in action (Score:2, Troll) Prioritize things (Score:2) I'd prioritize updating Java 8 applications to Java 11 first. Those are going to be the hardest to bring up-to-date with Java 25 (latest LTS), bringing them up to Java 11 buys the most time. Then upgrade to Java 25 starting with Java 17 applications, then Java 21, then Java 11. Remember that Java 25 will end support in 2033, so plan on starting your upgrade from Java 25 to the next LTS version basically as soon as your last upgrades to Java 25 are done. Re: (Score:2) Why (Score:3) Re: (Score:2) We don't. We use OpenJDK. Oracle Java is based on OpenJDK also. So you really think (Score:3) We still have code running on Java 6! Better to EOL (Score:2) Cost comparison? (Score:2) Go back to COBOL (Score:3) Re: (Score:3) See https://www.iso.org/standard/7... [iso.org] And for the history of COBOL language standardization, see the table here https://en.wikipedia.org/wiki/... [wikipedia.org] Programming languages managed buy ISO committees change slowly. That's a FEATURE. I worked a bit on the Ada standard. Each proposed change was carefully weighed for its impact on existing code, as well as the value for new code. The standard was updated roughly every 10 years.