Four LTS Java Versions Get End-of-Support in a Three-Year Window (2029-2032) (infoworld.com)
- Reference: 0183813776
- News link: https://developers.slashdot.org/story/26/06/14/0534214/four-lts-java-versions-get-end-of-support-in-a-three-year-window-2029-2032
- Source link: https://www.infoworld.com/article/4180981/its-crunch-time-for-java-modernization.html
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."
[1] https://www.infoworld.com/article/4180981/its-crunch-time-for-java-modernization.html
Upgrading multiple Java versions at once is easy (Score:1)
The Java language and standard library has great backwards-compatibility, while it adds useful features and enhancements version by version. It really is not that difficult to just jump to the latest Java version no matter what your current version is. There's no reason to spend a lot of effort doing small version jumps at a time. One could say jump from Java 8 to Java 25 in about the same amount of effort as going from 8 to 11, especially when they have a window of several years to do it in, and most ex
Re: (Score:2)
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
Capitalism in action (Score:2)
There's no bonus in staying up to date for this or any quarter, so...
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.
I'm wetting my pants now (Score:1)
We are still on Java8 with our entreprise software
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: [1]https://ops.java/releases/ [ops.java]
[1] https://ops.java/releases/
Re: (Score:2)
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 bro
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: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): [1]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.
[1] https://www.azul.com/products/azul-support-roadmap/