9 ms·

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

by 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.

by krzyk 5y ago

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.