3 ms·

Is Java 8 still an important minimum target?

foxyv 2y ago
Often it is significantly cheaper to pay for a longer term supported release of an older Java version than it is to upgrade your application to use a later release. So yeah, kinda?
otobrglez 2y ago
You would be surprised - or rather shocked - how many enterprises still run on it.
- kaba0 2y ago
  Though to be fair, since a few years ago Java 8 is no longer the most popular java version.
- creshal 2y ago
  We just finished upgrading all our Java 1.2 code to Java 17, the Java 6 projects are next :) I doubt we'll get around to the Java 8 stuff before 2030.
  - pandemic_region 2y ago
    Interesting, and a testimony to the stability of the jdk in a way. Did you use any automation tools for the migration I wonder?
    - creshal 2y ago
      The new code was written by a different department, so I'm a little hazy on the details, but I doubt it. It's a 25 years old line of business app, and it's in violation of every guideline, rule and law it touches, and only alive because it got grandfathered through various certifications and audits. 99% of the work was redesigning the business process it supports to be in compliance, and then write a new LOB app that takes inspiration from the old one, but works with the new process. You might be able to use AI for the remaining 1% mind- and pointless boilerplate code Java requires for no good reason.
  - ludicrousdispla 2y ago
    Are you hiring?
    - miningape 2y ago
      Trust me, you don't want that job :D I've been fighting to get our services to Java 21 from Java 8/11 for the last year or so, I've been partially successful but our main API (and 1/2 monolith) is still a dropwizard app on Java 11
  - yardstick 2y ago
    I expect 1.2 isn’t as bad as going from 1.4 or 8, not as many javax packages back then?
jillesvangurp 2y ago
No, it's a long deprecated JVM that is effectively abandoned. But it's still a good minimum target as all of its successors tend to be backwards compatible. But you'd typically use one of the more recent LTS versions. Of course there are quite a few crypto libraries out there, including several JWT related ones. A challenge in that space is that there have of course been some platform changes over the years. Not all of the newer algorithms are supported in older JDKs. And some of the alternatives are a bit complicated in terms of dependencies. I've had some issues with some of Google's libraries dragging in everything and the kitchen sink in terms of dependencies and then causing conflicts with my other dependencies when one of those dependencies changes their API. This one looks like it builds on bouncycastle and not much else. Which explains how it is not really that dependent on what comes with the JDK as bouncy castle provides its own implementations for a lot of the popular crypto stuff.
- tveita 2y ago
  This doesn't depend on BouncyCastle AFAICT, by default it uses javax.crypto but you can change it for a BouncyCastle security provider. https://github.com/FusionAuth/fusionauth-jwt/blob/main/src/main/java/io/fusionauth/security/DefaultCryptoProvider.java https://github.com/FusionAuth/fusionauth-jwt/blob/main/src/m...

Often it is significantly cheaper to pay for a longer term supported release of an older Java version than it is to upgrade your application to use a later release. So yeah, kinda?

otobrglez 2y ago

You would be surprised - or rather shocked - how many enterprises still run on it.

kaba0 2y ago
Though to be fair, since a few years ago Java 8 is no longer the most popular java version.
creshal 2y ago
We just finished upgrading all our Java 1.2 code to Java 17, the Java 6 projects are next :) I doubt we'll get around to the Java 8 stuff before 2030.
- pandemic_region 2y ago
  Interesting, and a testimony to the stability of the jdk in a way. Did you use any automation tools for the migration I wonder?
  - creshal 2y ago
    The new code was written by a different department, so I'm a little hazy on the details, but I doubt it. It's a 25 years old line of business app, and it's in violation of every guideline, rule and law it touches, and only alive because it got grandfathered through various certifications and audits. 99% of the work was redesigning the business process it supports to be in compliance, and then write a new LOB app that takes inspiration from the old one, but works with the new process. You might be able to use AI for the remaining 1% mind- and pointless boilerplate code Java requires for no good reason.
- ludicrousdispla 2y ago
  Are you hiring?
  - miningape 2y ago
    Trust me, you don't want that job :D I've been fighting to get our services to Java 21 from Java 8/11 for the last year or so, I've been partially successful but our main API (and 1/2 monolith) is still a dropwizard app on Java 11
- yardstick 2y ago
  I expect 1.2 isn’t as bad as going from 1.4 or 8, not as many javax packages back then?

jillesvangurp 2y ago

No, it's a long deprecated JVM that is effectively abandoned. But it's still a good minimum target as all of its successors tend to be backwards compatible. But you'd typically use one of the more recent LTS versions. Of course there are quite a few crypto libraries out there, including several JWT related ones. A challenge in that space is that there have of course been some platform changes over the years. Not all of the newer algorithms are supported in older JDKs. And some of the alternatives are a bit complicated in terms of dependencies. I've had some issues with some of Google's libraries dragging in everything and the kitchen sink in terms of dependencies and then causing conflicts with my other dependencies when one of those dependencies changes their API. This one looks like it builds on bouncycastle and not much else. Which explains how it is not really that dependent on what comes with the JDK as bouncy castle provides its own implementations for a lot of the popular crypto stuff.

tveita 2y ago
This doesn't depend on BouncyCastle AFAICT, by default it uses javax.crypto but you can change it for a BouncyCastle security provider. https://github.com/FusionAuth/fusionauth-jwt/blob/main/src/main/java/io/fusionauth/security/DefaultCryptoProvider.java https://github.com/FusionAuth/fusionauth-jwt/blob/main/src/m...