21–30 of 258 posts
For those of us supporting more than a few legacy apps, use the oldest version (7 in our case) because then there's less chance of things going wrong (depends, of course, whether you bill per support call or a fixed annual fee).
I don't understand this way of thinking, do you also run RHEL 4 on your servers?
The general guidance is always use the last LTS release unless there is a specific feature in the non LTS releases that you can’t wait for. So any new development should target 17 at this point. Unless you want serious long term pain then you shouldn’t be more than one LTS release behind. So if you are not running on JDK 11 or later you should be strongly thinking about upgrading.
Upgrades now are pretty straightforward if you are past JKD 9 - with JDK 16-17 being a bit tricky, but less than JDK 9.
For those of us supporting more than a few legacy apps, use the oldest version (7 in our case) because then there's less chance of things going wrong (depends, of course, whether you bill per support call or a fixed annual fee).
I don't understand this way of thinking, do you also run RHEL 4 on your servers?
Yeah I agree we should be using 17 except Gradle still does not support it, despite having been out for an entire month... https://docs.gradle.org/current/userguide/compatibility.html
Isn't that kind of thing you'd expect using Gradle? It's not the first time it happened, they have been late to the party for a lot of the recent releases.
The general guidance is always use the last LTS release unless there is a specific feature in the non LTS releases that you can’t wait for. So any new development should target 17 at this point. Unless you want serious long term pain then you shouldn’t be more than one LTS release behind. So if you are not running on JDK 11 or later you should be strongly thinking about upgrading.
Why should I stick to LTS? All other versions aren't in any way less tested, you should always stick to the newest released JDK version, be it LTS or not, this way you get all the benefits (language features, performance gains) and security ones (security fixes always first land in the newest version, and are backported to the older ones). Upgrades now are pretty straightforward if you are past JKD 9 - with JDK 16-17…
Source?
I'd like to see more of a rationale for not using Corretto on non-AWS servers. What's wrong with it?
The general guidance is always use the last LTS release unless there is a specific feature in the non LTS releases that you can’t wait for. So any new development should target 17 at this point. Unless you want serious long term pain then you shouldn’t be more than one LTS release behind. So if you are not running on JDK 11 or later you should be strongly thinking about upgrading.
They are in there but easy to miss - Bellsoft actually have builds for both jdks and jres for more than mainstream x86_64. Termurin dont even have jres anymore (last time I checked)
The general guidance is always use the last LTS release unless there is a specific feature in the non LTS releases that you can’t wait for. So any new development should target 17 at this point. Unless you want serious long term pain then you shouldn’t be more than one LTS release behind. So if you are not running on JDK 11 or later you should be strongly thinking about upgrading.
Why should I stick to LTS? All other versions aren't in any way less tested, you should always stick to the newest released JDK version, be it LTS or not, this way you get all the benefits (language features, performance gains) and security ones (security fixes always first land in the newest version, and are backported to the older ones). Upgrades now are pretty straightforward if you are past JKD 9 - with JDK 16-17…
Yeah I agree we should be using 17 except Gradle still does not support it, despite having been out for an entire month... https://docs.gradle.org/current/userguide/compatibility.html
Technically it's the Groovy runtime that doesn't support 17 (or specifically, JVM bytecode v62+) yet. And then only because it seems to do an explicit whitelisted-version check during some buildscript static-analysis bootstrap phase. If you switch your Gradle buildscript files over to being written in Kotlin, the problem goes away, as Kotlin's runtime doesn't seem to use any similar explicit checks. (Doing so also al…