4 ms·

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.
      - krzyk 2y ago
        Newer JDK usually means new features that makes programmers life easier -> less maintenance in the long run. This is not construction work, this is programming, new means better. If one doesn't have automated regression testing then that is a red light. You can do beta testing, with EA, not with GA.

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.
    - krzyk 2y ago
      Newer JDK usually means new features that makes programmers life easier -> less maintenance in the long run. This is not construction work, this is programming, new means better. If one doesn't have automated regression testing then that is a red light. You can do beta testing, with EA, not with GA.