Forgot your password?
Close
typodupeerror
Java Programming IT

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

Posted by EditorDavid from the support-groups dept.
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."
This discussion has been archived. No new comments can be posted.

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

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

Comments Filter:

  • I'm wetting my pants now (Score:3, Insightful)

    by trendzetter ( 777091 ) on Sunday June 14, 2026 @03:42AM (#66191222) Homepage Journal
    We are still on Java8 with our entreprise software

    • 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.)

      • Is that really a bad thing? There are certainly plenty of examples of old things that suck; either because genuine improvements became available after they had already solidified or because they were always broken and are now running purely on denial-fueled risk tolerance; but, in principle, it seems like it should be a bad thing that age is seen as a bad thing. Especially when software is more like math than like civil engineering in terms of the tendency of its materials toward corrosion, embrittlement, a

      • No one upgrades from a low number to a mid range number.

        Som guy above kind of suggested that, too.

        You upgrade to the current number, or one below.

        First you simply install the new Java, and start the old program.

        Then you figure, you have to write a module definition file, because the idiots could not resist to introduce modules into Java in a way that breaks all old code.

        And then, you decide if it is worth it to port it by: fixing all the damn problems the new version gives you.

        In general: it is not worth it

        • I have no idea why this Java "version" thing is even an issue on the internet. No one talks about C++ or C# issues, because there are none.

          Uh what? https://learn.microsoft.com/en... [microsoft.com] and Microsoft has also moved it to short support windows. It's not a Java or Microsoft thing it's an industry thing that Microsoft is a big proponent of.

          The MSVCRT absolutely is versioned too with its own issues, but now we're talking about the old school MS compatibility which has always been an outlier. It's not nothing, and anyone casually expecting that same treatment elsewhere is an idiot and taking what Microsoft pulled off for granted.

          You're talking about Ja

          • Java works on all platforms in general: the same.
            So does: Python, C# and what ever.

            There is no damn need to upgrade or change anything if for some braindead reason someone decides to change the Linux distro.

            That is the farking point of: "Write once, run anywhere",

        • Re: (Score:2)

          by cpurdy ( 4838085 )

          I have no idea why this Java "version" thing is even an issue on the internet. No one talks about C++ or C# issues, because there are none.

          C++ broke bigly going from 16- to 32-bit Windows, and again going from 32-bit to 64-bit Windows. And a lot of code that people had written broke bigly, too. But it was possible to write code in a very careful way to not break across these changes, which most people only figured out after the fact.

          As for C#, it used to break every single application with every single

          • Almost all Java 1.0 code written in '95, on the other hand, still runs fine today on Java 27 or whatever the latest version is.
            That is my experience, too.

            But why did you need to recompile 16/32 bit apps on windows?

      • This just seems so short-sighted. You spend a bunch of money familiarising with the code knowing that youâ(TM)ll be forced to do it again after youâ(TM)ve forgotten it. This is an opportunity to eliminate an unnecessary upgrade step. Each step of course will risk new and different regressions. Never mind that people donâ(TM)t find working on old code and tooling very motivational.

        Iâ(TM)m not so au fait with the Java world anymore, but in C++ land, there are some serious benefits from

      • Re: (Score:1)

        by trylak ( 935041 )
        Thats an odd statement... there are people who werent born yet when Java 21 came out in 2023.

    • Re: (Score:1)

      by breun ( 691628 )

      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.

  • 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:Upgrading multiple Java versions at once is eas (Score:5, Informative)

      by ls671 ( 1122017 ) on Sunday June 14, 2026 @05:39AM (#66191330) Homepage

      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:Upgrading multiple Java versions at once is eas (Score:4, Insightful)

        by El_Muerte_TDS ( 592157 ) on Sunday June 14, 2026 @06:02AM (#66191342) Homepage

        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. These libraries are used a lot. In most cases you cannot simply drop in a new bytecode manipulating library. That's where you run into the part where you have to move your software to newer frameworks and libraries which then also mean you need to change some of your code to go to the jakarta packages. And then you need to hope your software didn't abused some undocumented behavior/features, or internals, of those frameworks.

        Yes, there is a high probability that your (enterprise) software will need code changes in order to run on newer JREs.

        • Re: (Score:2)

          by ls671 ( 1122017 )

          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

          • find me a java 8 enterprise application which doesn't use at least one of these package:
            Easy.

            What about your first entry:
            javax.accessibility
            Defines a contract between user-interface components and an assistive technology that provides access to those components.

            Why would that be used in an enterprise app?

            Did not check your other examples, as your question is not really making sense to me, Okay: 10 seconds ...
            What about the "sounds" package? I never used it. Enterprise or not.

            XML? You are aware that you onl

            • > Why would that be used in an enterprise app? You don't understand why an enterprise app would need to work with assistive technologies? This is something that baffles you?

              • An enterprise app has nothing to do with

                How your fat fingers are unable to interact with a laptop or why your eyes can not see the text on your screen, or why hitting shift 5 times opens a screen reader and so on

                Perhaps you do not know what an "enterprise app" is?

                Hint: it is software were no normal user is interacting with.

                • It would shock and astound Oracle, who publishes "enterprise apps" like their Enterprise Business Suite (hey look, it even says "enterprise" right there in the title, and is only marketed to large enterprise!) that they don't write and maintain frontend apps in Java. Oh, look, they're the publishers of Java too, so they just might know a thing or two about it.

                  It would similarly shock and astound the collected finance and purchasing organizations across the Fortune 500 that live in Oracle EBS all damn day m

                  • I think the arrogance and idiocy is you.

                    None of those softwares uses javax.accessibility

                    It would not serve any purpose.

                    Because your fat fingers only touch your screen, and not the "enterprise software" running on the backend

                    The backend does not know anything about your screen, your mouse or your keyboard.

            • What about your first entry:
              javax.accessibility
              Defines a contract between user-interface components and an assistive technology that provides access to those components.

              Why would that be used in an enterprise app?

              So you've never heard of the Americans with Disabilities Act, or the common practice of large enterprises wanting to conform to relevant federal and state laws where they do business that has to do with accommodating disabled workers and not discriminating against workers with protected disabilities?

              Or are you yet again opining on shit you have no context of?

              • Disabilities are irrelevant for enterprise apps.

                As no disabled person is interacting with the enterprise app.

                The app is behind a user interface ... which has to cover disabilities.

                Stupid idiots on the internet. Mentally disabled?

                What the fark does my back end server have to do with noticing you can not read your computer screen

                Nothing.

                javax.accessibility
                And other APIs are for desktop applications or tablet/phone where the DISABLED person needs HELP to interact with that SOFTWARE. The farking server behind y

        • Javax was/is part of the JRE, for example all of Swing, the old Java GUI library is in javax.

  • Capitalism in action (Score:3, Insightful)

    by TheMiddleRoad ( 1153113 ) on Sunday June 14, 2026 @05:00AM (#66191316)
    There's no bonus in staying up to date for this or any quarter, so...

    • No idea why this got modded troll.
      You are completely right.

      There are plenty of organizations that are still on Java 8.

      Customer facing software is behind a layer of HTML, and back ends that communicate with the outside are behind firewalls.

      There is no farking way that an outside can exploit a vulnerability based on knowing the Java version.

      And upgrading to another version only trades known (and fixed?) vulnerabilities to unknown and unfixed ones.

      What is the benefit of upgrading to a newer Java version if the

      • What is the benefit of upgrading to a newer Java version if the old system does not use any of the newer language features? Oooops, none of course.
        Does anyone upgrade to a newer C++ compiler and recompile the running system and redeploys it? I don't think so.

        I think you're thinking of C++ from a Microsoft POV I can tell from your other post, and that is an extreme outlier. A redistributable C++ runtime that ships alongside your app, can be updated independently, has a long support life, and mostly decoupled from the OS release lifetime. So for a Windows C++ app you have a different story.

        For C++ software on Linux (since we're talking about Java), your question is silly. No there is no benefit to you whatsoever but you're going to rebuild your software for RedHa

  • 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)

      by Luthair ( 847766 )
      Once you're past Java 9 most upgrades are easy

      • The language part, true. The problem is dependencies. Any time you upgrade, especially if you're jumping a large number of versions, you're going to have packages your code uses needing upgrades too. Those package upgrades will usually require code changes to accommodate. Some of those changes will require refactoring to handle structural changes needed for things to work right. That is usually where you end up down a rabbit-hole.

        • Re: (Score:2)

          by Luthair ( 847766 )
          For us getting from Java 8 to 11 was a big hurdle but most of the subsequent upgrades were relatively straight forward until the EE10 which was a block of work but was still simpler than getting to 11.

  • Why (Score:3)

    by phantomfive ( 622387 ) on Sunday June 14, 2026 @06:13AM (#66191350) Journal
    Why do people still use Oracle Java?

    • Re: (Score:2)

      by dvice ( 6309704 )

      We don't. We use OpenJDK. Oracle Java is based on OpenJDK also.

    • Because one way or the other, Oracle is always involved.
      Not sure why big organizations use it instead of heaving a small department which curates their own version.

  • So you really think (Score:3)

    by Tomahawk ( 1343 ) on Sunday June 14, 2026 @06:45AM (#66191364) Homepage
    that most organisations are even using a somewhat up-to-date release of those LTS versions? Or will be bothered to upgrade for any legacy apps?

    We still have code running on Java 6!
  • Than to have a COBOL like situation decades down the line. Same with the remaining Internet Explorer sites.
  • Obviously this would require coordinated action, and some people likely have other reasons to want to either poke at or kill legacy applications; but(since all those java versions are solidly post openjdk) I'd be very curious to know how the cost and risk associated with "modernize because java 18 is going eol!" would compare to just...not...having java 18 go eol. Unsexy maintenance project that you'd need to pay to have done, sure; but very plausibly better characterized and lower risk than trying to deal

  • Go back to COBOL (Score:4)

    by silvergig ( 7651900 ) on Sunday June 14, 2026 @08:56AM (#66191472)
    Use COBOL. It doesn't receive frequent updates. Duh.

  • ... so some hardware stuff that needs Java now I've got working with honest Windows 7 Internet Explorer in a VM. Even better, it works with Windows 98 !!! And of course it's blazing fast, and it takes under 100 MBs in total.

  • What company in their right mind would rely on a vendor that end of life's v8 LTS a year after v17 LTS?

    Just use OpenJDK.

    • Re: (Score:2)

      by cpurdy ( 4838085 )
      The reason that Oracle keeps offering and selling JDK 8 support for years past when they originally planned to is easy: Because so many companies are "stuck" on JDK 8, so why not offer super-expensive annual support for it? Betcha anything other companies (e.g. Azul) keep offering JDK 8 support, just because it's so lucrative.

  • Wouldn't the OpenJDK versions of these be supported by enterprise Linux vendors, like Red Hat [redhat.com] or SUSE?

    Granted, I don't see the "ELS-1" (extended life support) for the newest ones, but I'm unaware of whether that is because it hasn't been set yet or because there won't be any - unlike the previous OpenJDK versions.

  • multiple times. A database management utility needs to be installed on junior admin's machine, each time team staff rolls over.The app needs a recent JRE. Same for overseas end user who needs it for an integration. They either don't have Java at all or have an older version, invariably. Even people who should be responsible don't know how to upgrade Java, and maybe they have to go through a bureaucracy to do so. It is messy.

  • we're still on Java 11 anyway

Slashdot Top Deals

1: No code table for op: ++post

Close