5 ms·

Java 8 is still supported until at least 2026, so why not target it?

znpy 2y ago
because you'd be doing throwaway work, and 2026 is basically one year from now. actually you're doing worse than throwaway work: you're creating more work (one more thing to migrate to newer java in 2026).
- RedShift1 2y ago
  I've migrated projects from Java 8 to 21 with little changes, I think for a lightweight library like this it wouldn't even matter.
  - krzyk 2y ago
    Migrating anything at least somehow complicated past Java 8 is PITA. When you are at Java 9, you are half done. Full done if you don't use some libraries that abuse JVM (like lombok). For most of those it would be enough to upgrade to newest versions. BTW. Next year we will have Java 25.
    - RedShift1 2y ago
      But this library's only dependency is Jackson. I really don't see how much of a hurdle this would be to upgrade.
      - krzyk 2y ago
        Jackson has a good maintainer that keeps the library up to date. So no issues there.
    - lbourdages 2y ago
      Java 8 -> 11 upgrade was kind of a pain, and so was 11 -> 17. After that though, it's smooth sailing. I think breaking changes for the module system are over.
    - self_awareness 2y ago
      It's always better to stick to the LTS versions. Well, unless someone really needs bleeding edge features, but most people don't. Current LTS is Java 21, it's supported until 2028 -- a much longer timeline than Java 24.
      - krzyk 2y ago
        How is it better exactly? And why always? I would argue differently, it is better to use latest JDK, it always has best support and fixes. Most maintained libraries keep their code compatible with it, if one doesn't then I would be cautious in using it as it is a big red light, that notifies given maintainer doesn't have enough time, so any fixes might not get there in time (or ever). Think of it like a litmus test. LTS makes sense if you are paying for it and updating your JDK as soon as there is a release of LTS JDK (so AFAIR usually once every 1-2 months. Which is exactly what you would do with the current JDK.
        self_awareness 2y ago
        Because you won't have to schedule full compatibility testing of your app in order to find out that there were breaking changes in the newest JDK version that require the user to fix the app. You can just not update the major version of JRE for a long time. The JRE will still be updated with security fixes and bugs, but no breaking changes should be introduced. Developers can focus on extending functionality instead of maintenance and porting the app to new JRE. Devops can focus on different things than adapting the environment to the new requirements that were broken in new JRE major version. Product managers don't need to create another spreadsheet columns to mark compatibility issues. The problem with "most libraries keeping their code compatible with the newest JRE version" is that most projects use a library that is not kept up-to-date with the newest JRE version. Often that library is the library which has no alternatives. Also switching libraries is rarely a trivial thing to do. Using bleeding edge software also means that we participate in "beta" testing. Company-oriented human resource management would suggest that the resources the company spends should be about the needs of the company, not some thirdparty product.
        2y ago
- ktosobcy 2y ago
  You can use library targeting Java8 with Java 23 or even newer (assuming they don't use Unsafe or some weird workarounds not covered by the API)
Melonotromo 2y ago
[dead]
heelix 2y ago
Oracle broke compatibility between Java 8 and Java 9+, so many of the libraries that have a dependency on older functionality are not getting maintained. Java 8 is turning into a dangerous space because even though the JDK is getting patched quarterly, much of the components that work with it are not. It is only going to get worse. SpringBoot, for example, requires either a commercial contract for Java 8/11 support or Java 17+ for the community supported stuff.
- ktosobcy 2y ago
  What a FUD-fuelled bullst > Oracle broke compatibility between Java 8 and Java 9+, No it didn't. Introduction of modules (Java Platform Module System (JPMS)) would be mostly transparent to majority of users. > so many of the libraries that have a dependency on older functionality are not getting maintained. Any example? (I already herad the same argument on bluesky and asked for example and suprisingly didn't get it either) The biggest issue around that time was switching from javax to jakarta namespace but that's somewhat on the side of the Java versioning. > Java 8 is turning into a dangerous space because even though the JDK is getting patched quarterly, much of the components that work with it are not. Again - examples? If the library is not update then it could happen in any ecosystem - python, c# and whatnot. > It is only going to get worse. SpringBoot, for example, requires either a commercial contract for Java 8/11 support or Java 17+ for the community supported stuff. Of for f sake - if you are still stuck on Java 8 (released a decated ago) and didn't update then it's only your fault. Supporting ancient platform cost money so you either put that money to be up to date or you pay companies to maintain compatibility you ancient stock. MS is doing the same with old OSs and virtually any other company requires to pay/pay more to support old stuff... (because it costs money)
  - heelix 2y ago
    I'm coming in as someone who helped get thousands of Java 8 based SpringBoot 2.x apps to Java 17/21 and SpringBoot 3.x, so a non-trivial portion of my last year. The javax -> jakarta namespace was a part of the issue. Turns out, we had a lot of things using jaxb as either a direct or transient dependency. About 10% of the apps were some form of old school Java EE which faced the same issue. None of the porting is hard once you've sat down and done it once - but we had team after team who were doing it the first time. We also got to find out who was using deprecated packages, as release by release from 9+, they started to be deleted. Way too many libs were using Sun's base64 encoder. The point here is that Java is getting updated and the core JDK is just fine. We are seeing components drop support for Java 1-8, requiring 9+. And yes, that could happen in any ecosystem. It is happening in Java ecosystem today. If you crawl GitHub and look at what is vibrant and what is becoming abandoned, you will see the unmaintained legacy stuff stuck on Java 8. CVEs are a terrible way to say security risk - but it does show trends. Since about 80% of our Java apps are SpringBoot based, when SpringBoot 2.7.18 being the last 2.x community release that reached EOL in November of last year. That version released with Spring Framework 5.3.31 - Spring Framework is currently 5.3.41 or so for those getting commercial patching. This is the last version that supported Java 8 through 11. Similar issue with MapR. This traps people on specific Java versions, which then traps them to an aging ecosystem of components. The parent asked - why not target Java 8? That is why. If the parent asked, should I be compatible with Java 21-8, I'd say fine. It is a company's fault if they found themselves on an EOL product. Please, for the love of god... don't enable teams to remain there by making ANYTHING that requires Java 8. None of this is hard until you have so many that it is.

znpy 2y ago

because you'd be doing throwaway work, and 2026 is basically one year from now. actually you're doing worse than throwaway work: you're creating more work (one more thing to migrate to newer java in 2026).

RedShift1 2y ago
I've migrated projects from Java 8 to 21 with little changes, I think for a lightweight library like this it wouldn't even matter.
- krzyk 2y ago
  Migrating anything at least somehow complicated past Java 8 is PITA. When you are at Java 9, you are half done. Full done if you don't use some libraries that abuse JVM (like lombok). For most of those it would be enough to upgrade to newest versions. BTW. Next year we will have Java 25.
  - RedShift1 2y ago
    But this library's only dependency is Jackson. I really don't see how much of a hurdle this would be to upgrade.
    - krzyk 2y ago
      Jackson has a good maintainer that keeps the library up to date. So no issues there.
  - lbourdages 2y ago
    Java 8 -> 11 upgrade was kind of a pain, and so was 11 -> 17. After that though, it's smooth sailing. I think breaking changes for the module system are over.
  - self_awareness 2y ago
    It's always better to stick to the LTS versions. Well, unless someone really needs bleeding edge features, but most people don't. Current LTS is Java 21, it's supported until 2028 -- a much longer timeline than Java 24.
    - krzyk 2y ago
      How is it better exactly? And why always? I would argue differently, it is better to use latest JDK, it always has best support and fixes. Most maintained libraries keep their code compatible with it, if one doesn't then I would be cautious in using it as it is a big red light, that notifies given maintainer doesn't have enough time, so any fixes might not get there in time (or ever). Think of it like a litmus test. LTS makes sense if you are paying for it and updating your JDK as soon as there is a release of LTS JDK (so AFAIR usually once every 1-2 months. Which is exactly what you would do with the current JDK.
      - self_awareness 2y ago
        Because you won't have to schedule full compatibility testing of your app in order to find out that there were breaking changes in the newest JDK version that require the user to fix the app. You can just not update the major version of JRE for a long time. The JRE will still be updated with security fixes and bugs, but no breaking changes should be introduced. Developers can focus on extending functionality instead of maintenance and porting the app to new JRE. Devops can focus on different things than adapting the environment to the new requirements that were broken in new JRE major version. Product managers don't need to create another spreadsheet columns to mark compatibility issues. The problem with "most libraries keeping their code compatible with the newest JRE version" is that most projects use a library that is not kept up-to-date with the newest JRE version. Often that library is the library which has no alternatives. Also switching libraries is rarely a trivial thing to do. Using bleeding edge software also means that we participate in "beta" testing. Company-oriented human resource management would suggest that the resources the company spends should be about the needs of the company, not some thirdparty product.
        2y ago
ktosobcy 2y ago
You can use library targeting Java8 with Java 23 or even newer (assuming they don't use Unsafe or some weird workarounds not covered by the API)

Melonotromo 2y ago

[dead]

heelix 2y ago

Oracle broke compatibility between Java 8 and Java 9+, so many of the libraries that have a dependency on older functionality are not getting maintained. Java 8 is turning into a dangerous space because even though the JDK is getting patched quarterly, much of the components that work with it are not. It is only going to get worse. SpringBoot, for example, requires either a commercial contract for Java 8/11 support or Java 17+ for the community supported stuff.

ktosobcy 2y ago
What a FUD-fuelled bullst > Oracle broke compatibility between Java 8 and Java 9+, No it didn't. Introduction of modules (Java Platform Module System (JPMS)) would be mostly transparent to majority of users. > so many of the libraries that have a dependency on older functionality are not getting maintained. Any example? (I already herad the same argument on bluesky and asked for example and suprisingly didn't get it either) The biggest issue around that time was switching from javax to jakarta namespace but that's somewhat on the side of the Java versioning. > Java 8 is turning into a dangerous space because even though the JDK is getting patched quarterly, much of the components that work with it are not. Again - examples? If the library is not update then it could happen in any ecosystem - python, c# and whatnot. > It is only going to get worse. SpringBoot, for example, requires either a commercial contract for Java 8/11 support or Java 17+ for the community supported stuff. Of for f sake - if you are still stuck on Java 8 (released a decated ago) and didn't update then it's only your fault. Supporting ancient platform cost money so you either put that money to be up to date or you pay companies to maintain compatibility you ancient stock. MS is doing the same with old OSs and virtually any other company requires to pay/pay more to support old stuff... (because it costs money)
- heelix 2y ago
  I'm coming in as someone who helped get thousands of Java 8 based SpringBoot 2.x apps to Java 17/21 and SpringBoot 3.x, so a non-trivial portion of my last year. The javax -> jakarta namespace was a part of the issue. Turns out, we had a lot of things using jaxb as either a direct or transient dependency. About 10% of the apps were some form of old school Java EE which faced the same issue. None of the porting is hard once you've sat down and done it once - but we had team after team who were doing it the first time. We also got to find out who was using deprecated packages, as release by release from 9+, they started to be deleted. Way too many libs were using Sun's base64 encoder. The point here is that Java is getting updated and the core JDK is just fine. We are seeing components drop support for Java 1-8, requiring 9+. And yes, that could happen in any ecosystem. It is happening in Java ecosystem today. If you crawl GitHub and look at what is vibrant and what is becoming abandoned, you will see the unmaintained legacy stuff stuck on Java 8. CVEs are a terrible way to say security risk - but it does show trends. Since about 80% of our Java apps are SpringBoot based, when SpringBoot 2.7.18 being the last 2.x community release that reached EOL in November of last year. That version released with Spring Framework 5.3.31 - Spring Framework is currently 5.3.41 or so for those getting commercial patching. This is the last version that supported Java 8 through 11. Similar issue with MapR. This traps people on specific Java versions, which then traps them to an aging ecosystem of components. The parent asked - why not target Java 8? That is why. If the parent asked, should I be compatible with Java 21-8, I'd say fine. It is a company's fault if they found themselves on an EOL product. Please, for the love of god... don't enable teams to remain there by making ANYTHING that requires Java 8. None of this is hard until you have so many that it is.