12 ms·

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 developme

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.

krzyk 5y ago
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 being a bit tricky, but less than JDK 9.
- throw63738 5y ago
  》All other versions aren't in any way less tested Source?
  - evercast 5y ago
    OpenJDK serves as the upstream for many Java distributions (maybe all?) and it has no notion of LTS. LTS is just something to which vendors commit as outlined at https://openjdk.java.net/projects/jdk/17/ https://openjdk.java.net/projects/jdk/17/ : “JDK 17 will be a long-term support (LTS) release from most vendors.”. In other words, OpenJDK does not follow any LTS/non-LTS release cycle. Hence there is nothing special about Java 17 vs 16 when it comes to stability.
  - krzyk 5y ago
    Even preview features are production ready (I used them in production) . Just the api might change or it could be removed, but quality wise it is as good as it can be.
- klodolph 5y ago
  The JDK itself may receive a similar amount of testing upstream, but libraries downstream tend to receive more testing on LTS JDKs.
  - krzyk 5y ago
    Maybe, but those I use didn have any trouble with any java release. Using so called LTS without paying for it is in no way different from using latest. You get similarly tested software and no one to call if you need a security fix asap.
- Zababa 5y ago
  > All other versions aren't in any way less tested That depends. If most people follow the advice of "sticking to LTS", these versions will have way more users, and thus will be more "battle-tested", as in tested in production.
- colechristensen 5y ago
  In large installations I have almost always had problems, some little, some big with major version upgrades of Java.
- shartacct 5y ago
  > (language features, performance gains) There haven't been any notable language features added since java 9 besides some basic syntax sugar (which is already covered by stuff like lombok anyway). For features and performance you might as well just target .NET 6. It has things that have been perpetually 'too hard to implement' (read: oracle doesn't want to pay their engineers to impl it and will sue you if you do it yourself) like value types, generics without type erasure, no checked exceptions, etc. and with .NET 6 performance is better than OpenJDK across the board.
  - vips7L 5y ago
    > read: oracle doesn't want to pay their engineers to impl it and will sue you if you do it yourself) like value types, generics without type erasure, no checked exceptions, etc. All of this is currently being implemented in project Valhalla...
    - throw868788 5y ago
      I never buy into the tech stack argument that things are being worked on (e.g you mention Project Vahalla but I see this across many languages and tools). Seen this argument used on a number of different technologies. It compares a future state to a current state to put the favored tech (the future state) in an equal or better position. It usually punishes innovative platforms as well; because it dismisses any reason to take them up. It's comparing apples to oranges - in this case .NET is also being actively worked on so may have other things by then. Compare current state only. The truth is each platform has prioritized features relevant to its context. For what its worth in my experience while the JVM has many more JIT optimisations and the like it tends to need them more of them given the lack of some of those features you mention (e.g. value types). Whereas .NET code allows value types, better management of memory (i.e. Span), reified generics etc so the focus has been to allow the user to optimise themselves where required where still allowing for a decent performance default. Many of the optimisations in the JVM wouldn't have the same bang for buck in .NET and vice versa. On a personal note I'm more of a fan of the .NET philosophy because the code is usually fast enough, and when I need to tune memory, avoid allocations, and do fast code it seems to offer more tools not in an unsafe context to do so. It allows a better "upper bound" of performance for core things IMO while keeping to bytecode/IL. Many benchmarks where the same level of application optimisation has occured from what I seen have confirmed this bias for me. YMMV
- fwip 5y ago
  Some people who want to run your software may have a policy of only running LTS versions. In some cases, this may be your ops team.
- erikerikson 5y ago
  LTS = long term support Support for vulnerability patches, stability, and so on. You can automatically update and maybe that goes well and maybe problems are caught in testing. Regardless those events and changes have over time have increased costs. LTS should mean lower costs both through increased support focus, increased population of active users, and reduced forced change. You're not wrong...
  - krzyk 5y ago
    But if you don't buy LTS you won't get it. And many companies are cheap and don't buy - hence using JDK 17 won't give you LTS, buying support gives you LTS.
    - dikei 5y ago
      JDK 11 is now at 11.0.12, which was released in July, and you can get it for free from multiple vendors. Non-LTS JDK doesn't have anything after 6 months.
      - krzyk 5y ago
        After 6 months you move to the next release, just like most people do with libraries, JDK is just another library, no need to worry about upgrading, just do normal regression like with upgrades of other libs. There are no major releases of JDK, all current ones are minor ones - just like in case of JDK 8 you got new features in minor releases (e.g. change in changing of toString, added classes in standard library - no one was worried about that then) And BTW. Azul MTS want's to have a word with you: https://www.azul.com/products/azul-support-roadmap/ https://www.azul.com/products/azul-support-roadmap/ e.g. JDK 13 and 15 do get builds.
DarkmSparks 5y ago
There is more to this now tho, because even their topline recommendation misses the fact that Temurin (anagram of runtime) only provides a small subset of tested builds you need. 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) https://bell-sw.com/pages/downloads/#/java-17-current https://bell-sw.com/pages/downloads/#/java-17-current
- krzyk 5y ago
  Are JREs still a thing (they were removed from Oracle builds in JDK 9)? Those were mostly for applets or JWS. Nowadays no one keeps just one JRE in their laptop/desktop and disk sizes are in TBs so no point in saving 100 MB and lacking development tools. And in one targets containers or systems with small amount of disk jlink give more gains than JRE.
  - DarkmSparks 5y ago
    If you are distributing software based on java a 40mb jre in place of a 400mb jdk is surely preferred. You can build them yourself for each OS you target with jlink, or you can just grab the latest built and tested one from e.g. Bellsoft - but not Adoptium or Oracle. Java has been "breaking changes" between releases to make python blush for a few years now, 17 finally looks like a worthy migration from 8.
    - krzyk 5y ago
      JRE is like 44MB, JDK is 190MB. Difference is not 400 MB. And you get jshell, javac all the nice tools that I missed when some wise guys in distro or corp decided JRE is enough.
      - DarkmSparks 5y ago
        not when extracted they arent. And jlink wont help you get a jdk for 32bit arm
pron 5y ago
The safest, cheapest choice for applications that are heavily maintained is to use the most recent version. LTS is designed for legacy applications that are no longer heavily developed, and might benefit from security and bug fixes only (note that this model is new; in the past, back when there were major versions, minor updates included both patches and big features).
- fwip 5y ago
  It also depends on your target environment, and how much control you can exert over the machine where your software will run. Sometimes you're creating an app that other users need to run in their own environments - and in that case, targeting "latest LTS" is safer, as they may have requirements on what they can run that you don't.
  - pron 5y ago
    True, there are, indeed, times when you can't use the current version, but note that Java applications are now encouraged to bundle their own runtime (generated with jlink).
- karmakaze 5y ago
  'heavily developed' is the operative consideration as this means upgrading (not merely updating) your Java installations every 6 months.
  - pron 5y ago
    With major releases gone, this isn't hard, and, overall cheaper and easier than upgrading less frequently. But it is some work, which is why the LTS service was added for the benefit of legacy applications. Note that under the old model, LTS didn't exist. There was a new feature release every six months that everyone had to upgrade to. The names of those releases didn't stand out as much (8u20, 8u40 for feature releases [1] as opposed to, say, 8u25, 8u45 for patches) as they do now when we did away with major releases and gave every new feature release a new integer number. Because now the feature releases can add new APIs rather than just new JVM features as they did under the old model, this process can be slightly more work, but still significantly less work over time. As regularly maintained applications update code and dependencies regularly, anyway, this is a clear win. Not only is the upgrade process easier and cheaper, but you get to enjoy the regular and significant performance improvements that have always been part of the six-monthly feature releases, but aren't in the LTS patches. [1]: Those feature releases under the old model also added major new features with significant changes to the VM. For example, the G1 GC and JFR were added in feature releases.
KronisLV 5y ago
Currently upgrading a ~1M SLoC Java enterprise app (with regular Spring, Jetty in there, scheduled processes, PrimeFaces for web UI, REST API services, SOAP services, the whole shebang) from Java 8 to Java 11 (since 17 wasn't out when that change was approved) and it's largely proving to be a pain. Since the version of Spring is ancient and changes over to Spring Boot were also approved, now have to rewrite parts of it and also get rid of the XML configuration and other old approaches which are simply no longer compatible with this upgraded tech stack. It feels like something that perhaps a team should do, instead of one dev over a month or so, but scope creep and estimates for something like that are nigh impossible, so we'll see. My point is that migrating to new releases isn't always trivial, especially the more complicated and complex a project gets. If i knew that i'll run if compiled successfully, then it wouldn't be too bad, but with the amount of reflection, dynamic class loading etc. that frameworks like Spring favor, my workflow to date has been fixing a bug, building and running, something else breaking, fixing that bug, building and running, something else breaking, realizing that i cannot fix this because upgrades to the logic would be inherently "lossy" due to a mismatch of what the new framework versions provide, making it so that breakages that aren't covered by tests will also be created and so on ad infinitum. Sometimes it makes me wonder why JDK 9 onward just didn't have a compatibility module: "Here, install this to have all of the old Java classes that were removed from the standard library after JDK 8 and retain that old functionality for software projects that would otherwise be stuck in development hell short of a full rewrite." Or something like that for Spring Boot, that lets you use web.xml instead of having to use hacks to load its contents and register all of the servlets, with half of them not working anyways, because some class names were changed along the way. Software doesn't always age beautifully. Furthermore, it feels like new runtime and package versions are made in ways that accidentally break backwards compatibility with no clear ways to avoid this.
- virtue3 5y ago
  I think this is one of the few benefits of micro service architectures. You end up with much smaller pieces to migrate over. And if the service is well defined and you have ample logging for endpoints you actually could re-write it. Mind you; you usually end up with the services all in different states of node/jdk/etc versioning(at least the companies I worked at).

krzyk 5y ago

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 being a bit tricky, but less than JDK 9.

throw63738 5y ago
》All other versions aren't in any way less tested Source?
- evercast 5y ago
  OpenJDK serves as the upstream for many Java distributions (maybe all?) and it has no notion of LTS. LTS is just something to which vendors commit as outlined at https://openjdk.java.net/projects/jdk/17/ https://openjdk.java.net/projects/jdk/17/ : “JDK 17 will be a long-term support (LTS) release from most vendors.”. In other words, OpenJDK does not follow any LTS/non-LTS release cycle. Hence there is nothing special about Java 17 vs 16 when it comes to stability.
- krzyk 5y ago
  Even preview features are production ready (I used them in production) . Just the api might change or it could be removed, but quality wise it is as good as it can be.
klodolph 5y ago
The JDK itself may receive a similar amount of testing upstream, but libraries downstream tend to receive more testing on LTS JDKs.
- krzyk 5y ago
  Maybe, but those I use didn have any trouble with any java release. Using so called LTS without paying for it is in no way different from using latest. You get similarly tested software and no one to call if you need a security fix asap.
Zababa 5y ago
> All other versions aren't in any way less tested That depends. If most people follow the advice of "sticking to LTS", these versions will have way more users, and thus will be more "battle-tested", as in tested in production.
colechristensen 5y ago
In large installations I have almost always had problems, some little, some big with major version upgrades of Java.
shartacct 5y ago
> (language features, performance gains) There haven't been any notable language features added since java 9 besides some basic syntax sugar (which is already covered by stuff like lombok anyway). For features and performance you might as well just target .NET 6. It has things that have been perpetually 'too hard to implement' (read: oracle doesn't want to pay their engineers to impl it and will sue you if you do it yourself) like value types, generics without type erasure, no checked exceptions, etc. and with .NET 6 performance is better than OpenJDK across the board.
- vips7L 5y ago
  > read: oracle doesn't want to pay their engineers to impl it and will sue you if you do it yourself) like value types, generics without type erasure, no checked exceptions, etc. All of this is currently being implemented in project Valhalla...
  - throw868788 5y ago
    I never buy into the tech stack argument that things are being worked on (e.g you mention Project Vahalla but I see this across many languages and tools). Seen this argument used on a number of different technologies. It compares a future state to a current state to put the favored tech (the future state) in an equal or better position. It usually punishes innovative platforms as well; because it dismisses any reason to take them up. It's comparing apples to oranges - in this case .NET is also being actively worked on so may have other things by then. Compare current state only. The truth is each platform has prioritized features relevant to its context. For what its worth in my experience while the JVM has many more JIT optimisations and the like it tends to need them more of them given the lack of some of those features you mention (e.g. value types). Whereas .NET code allows value types, better management of memory (i.e. Span), reified generics etc so the focus has been to allow the user to optimise themselves where required where still allowing for a decent performance default. Many of the optimisations in the JVM wouldn't have the same bang for buck in .NET and vice versa. On a personal note I'm more of a fan of the .NET philosophy because the code is usually fast enough, and when I need to tune memory, avoid allocations, and do fast code it seems to offer more tools not in an unsafe context to do so. It allows a better "upper bound" of performance for core things IMO while keeping to bytecode/IL. Many benchmarks where the same level of application optimisation has occured from what I seen have confirmed this bias for me. YMMV
fwip 5y ago
Some people who want to run your software may have a policy of only running LTS versions. In some cases, this may be your ops team.
erikerikson 5y ago
LTS = long term support Support for vulnerability patches, stability, and so on. You can automatically update and maybe that goes well and maybe problems are caught in testing. Regardless those events and changes have over time have increased costs. LTS should mean lower costs both through increased support focus, increased population of active users, and reduced forced change. You're not wrong...
- krzyk 5y ago
  But if you don't buy LTS you won't get it. And many companies are cheap and don't buy - hence using JDK 17 won't give you LTS, buying support gives you LTS.
  - dikei 5y ago
    JDK 11 is now at 11.0.12, which was released in July, and you can get it for free from multiple vendors. Non-LTS JDK doesn't have anything after 6 months.
    - krzyk 5y ago
      After 6 months you move to the next release, just like most people do with libraries, JDK is just another library, no need to worry about upgrading, just do normal regression like with upgrades of other libs. There are no major releases of JDK, all current ones are minor ones - just like in case of JDK 8 you got new features in minor releases (e.g. change in changing of toString, added classes in standard library - no one was worried about that then) And BTW. Azul MTS want's to have a word with you: https://www.azul.com/products/azul-support-roadmap/ https://www.azul.com/products/azul-support-roadmap/ e.g. JDK 13 and 15 do get builds.

DarkmSparks 5y ago

There is more to this now tho, because even their topline recommendation misses the fact that Temurin (anagram of runtime) only provides a small subset of tested builds you need. 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) https://bell-sw.com/pages/downloads/#/java-17-current https://bell-sw.com/pages/downloads/#/java-17-current

krzyk 5y ago
Are JREs still a thing (they were removed from Oracle builds in JDK 9)? Those were mostly for applets or JWS. Nowadays no one keeps just one JRE in their laptop/desktop and disk sizes are in TBs so no point in saving 100 MB and lacking development tools. And in one targets containers or systems with small amount of disk jlink give more gains than JRE.
- DarkmSparks 5y ago
  If you are distributing software based on java a 40mb jre in place of a 400mb jdk is surely preferred. You can build them yourself for each OS you target with jlink, or you can just grab the latest built and tested one from e.g. Bellsoft - but not Adoptium or Oracle. Java has been "breaking changes" between releases to make python blush for a few years now, 17 finally looks like a worthy migration from 8.
  - krzyk 5y ago
    JRE is like 44MB, JDK is 190MB. Difference is not 400 MB. And you get jshell, javac all the nice tools that I missed when some wise guys in distro or corp decided JRE is enough.
    - DarkmSparks 5y ago
      not when extracted they arent. And jlink wont help you get a jdk for 32bit arm

pron 5y ago

The safest, cheapest choice for applications that are heavily maintained is to use the most recent version. LTS is designed for legacy applications that are no longer heavily developed, and might benefit from security and bug fixes only (note that this model is new; in the past, back when there were major versions, minor updates included both patches and big features).

fwip 5y ago
It also depends on your target environment, and how much control you can exert over the machine where your software will run. Sometimes you're creating an app that other users need to run in their own environments - and in that case, targeting "latest LTS" is safer, as they may have requirements on what they can run that you don't.
- pron 5y ago
  True, there are, indeed, times when you can't use the current version, but note that Java applications are now encouraged to bundle their own runtime (generated with jlink).
karmakaze 5y ago
'heavily developed' is the operative consideration as this means upgrading (not merely updating) your Java installations every 6 months.
- pron 5y ago
  With major releases gone, this isn't hard, and, overall cheaper and easier than upgrading less frequently. But it is some work, which is why the LTS service was added for the benefit of legacy applications. Note that under the old model, LTS didn't exist. There was a new feature release every six months that everyone had to upgrade to. The names of those releases didn't stand out as much (8u20, 8u40 for feature releases [1] as opposed to, say, 8u25, 8u45 for patches) as they do now when we did away with major releases and gave every new feature release a new integer number. Because now the feature releases can add new APIs rather than just new JVM features as they did under the old model, this process can be slightly more work, but still significantly less work over time. As regularly maintained applications update code and dependencies regularly, anyway, this is a clear win. Not only is the upgrade process easier and cheaper, but you get to enjoy the regular and significant performance improvements that have always been part of the six-monthly feature releases, but aren't in the LTS patches. [1]: Those feature releases under the old model also added major new features with significant changes to the VM. For example, the G1 GC and JFR were added in feature releases.

KronisLV 5y ago

Currently upgrading a ~1M SLoC Java enterprise app (with regular Spring, Jetty in there, scheduled processes, PrimeFaces for web UI, REST API services, SOAP services, the whole shebang) from Java 8 to Java 11 (since 17 wasn't out when that change was approved) and it's largely proving to be a pain. Since the version of Spring is ancient and changes over to Spring Boot were also approved, now have to rewrite parts of it and also get rid of the XML configuration and other old approaches which are simply no longer compatible with this upgraded tech stack. It feels like something that perhaps a team should do, instead of one dev over a month or so, but scope creep and estimates for something like that are nigh impossible, so we'll see. My point is that migrating to new releases isn't always trivial, especially the more complicated and complex a project gets. If i knew that i'll run if compiled successfully, then it wouldn't be too bad, but with the amount of reflection, dynamic class loading etc. that frameworks like Spring favor, my workflow to date has been fixing a bug, building and running, something else breaking, fixing that bug, building and running, something else breaking, realizing that i cannot fix this because upgrades to the logic would be inherently "lossy" due to a mismatch of what the new framework versions provide, making it so that breakages that aren't covered by tests will also be created and so on ad infinitum. Sometimes it makes me wonder why JDK 9 onward just didn't have a compatibility module: "Here, install this to have all of the old Java classes that were removed from the standard library after JDK 8 and retain that old functionality for software projects that would otherwise be stuck in development hell short of a full rewrite." Or something like that for Spring Boot, that lets you use web.xml instead of having to use hacks to load its contents and register all of the servlets, with half of them not working anyways, because some class names were changed along the way. Software doesn't always age beautifully. Furthermore, it feels like new runtime and package versions are made in ways that accidentally break backwards compatibility with no clear ways to avoid this.

virtue3 5y ago
I think this is one of the few benefits of micro service architectures. You end up with much smaller pieces to migrate over. And if the service is well defined and you have ample logging for endpoints you actually could re-write it. Mind you; you usually end up with the services all in different states of node/jdk/etc versioning(at least the companies I worked at).