4 ms·

Java doesn't have LTS versions. All versions are equal, and vendors sell long-term support services to arbitrary versions of their choosing. The most recent ver

by pron 6y ago

Java doesn't have LTS versions. All versions are equal, and vendors sell long-term support services to arbitrary versions of their choosing. The most recent version you can buy an LTS service for from Oracle is 11, and most, though not all vendors pick the same versions as Oracle for their support service. BTW, LTS is mostly designed for legacy applications, i.e. those that don't see much development. The recommended version for use in production by applications that are heavily maintained is always the current version (15, and soon 16). It is true, however, that many people still misunderstand Java's LTS, and perhaps confuse it with the notion of LTS in other ecosystems, and so many choose an old version and buy LTS even if it's not the best option for them. (I work at Oracle on OpenJDK)

tyingq 6y ago
Sure, so if I go to adoptopenjdk, the home page offers up 2 LTS versions (8,11) , and "LATEST". Same for Amazon's Corretto. And they all make note of LTS or not. I believe you, but that message isn't front and center on the various OpenJDK distributions.
- pron 6y ago
  Sadly, while Java is otherwise careful to enforce various standards, anyone is free to call whatever they like LTS. OpenJDK (the source of most JDK distributions) has no concept of LTS (e.g., you'll find no mention of LTS here: https://openjdk.java.net/projects/jdk/11/ https://openjdk.java.net/projects/jdk/11/). Different vendors can call LTS whatever they like, and what that actually entails depends on the vendor. If we define LTS to at least include long-term maintenance in the form of bug and security fixes of the entire JDK, then no one offers a free LTS. Free offerings that call themselves LTS are just builds of the OpenJDK Updates project, that backports fixes from mainline, and so only includes fixes for the intersection of the old version and the current one (i.e. no "free LTS" offers patches for, say, CMS or Nashorn, and multiple other components that exist in 11 or 8 but not in 16). "Free LTS" offerings are only recommended for legacy hobby projects. Important production software should use either the current version (free) or buy an LTS service for an old version from some trusted vendor. The only version that is fully and freely maintained is the current one, and it also offers the cheapest upgrade process and the best performance. Don't think that if the vendor calls something LTS and ships updates that include some fixes you're actually getting some fully-maintained JDK. BTW, AdoptOpenJDK is not affiliated or involved with OpenJDK, and is made by an IBM team that is exceptionally uninvolved and unfamiliar with OpenJDK compared to all other OpenJDK distributions (Oracle, Red Hat, SAP, Azul, Bellsoft, and Amazon).
  - scns 6y ago
    Hm, my impression is that usually OpenJDK 8 is the fastest: https://www.phoronix.com/scan.php?page=article&item=openjdk-14-benchmark&num=5 https://www.phoronix.com/scan.php?page=article&item=openjdk-... https://www.phoronix.com/scan.php?page=article&item=graalvm201-openj920-jvm&num=5 https://www.phoronix.com/scan.php?page=article&item=graalvm2... (edit: added missing version (slighly embarassed) and second link)
    - pron 6y ago
      It's definitely the slowest, and by pretty significant margins. Those tests did, however, uncover bad default settings in JDK 14 on some machine sizes, which happened to be those Phoronix ran their benchmarks on: https://kstefanj.github.io/2020/04/16/g1-ootb-performance.html https://kstefanj.github.io/2020/04/16/g1-ootb-performance.ht... Those bad defaults are fixed in 15. Moving away from 8 results in a significant saving in hardware/hosting costs for the vast majority of large applications.
- cesarb 6y ago
  Linux distributions too, they all seem to offer three Java packages: one for Java 8, one for Java 11, and one for Java "latest". The default is either the Java 8 one or the Java 11 one.
dcminter 6y ago
I've seen a reluctance to move from Java 8 because of the issues upgrading past Jigsaw (e.g. the build I'm working on today bleeds warnings about groovy doing illegal reflective access - and that's just a cosmetic issue) and so many shops decided to wait until the "LTS" Java 11 came along to make the jump. Now that they're there and with the memory of the upgrade pain there's reluctance to upgrade again before Java 17. I think once they do that and see a much more normal upgrade path for that leap they'll be a lot more willing to track all the releases and not just the LTS ones (real or not it's perceived as being a thing).
- pron 6y ago
  I agree. Funnily enough, though, the upgrade pain to 9+ had nothing to do with Jigsaw, because its encapsulation hasn't even been turned on (unless you count warnings). It was just the biggest and most visible change, so people blamed their unrelated upgrade issues on it. The actual cause for many issues was that some popular libraries hacked into off-specification, undocumented JDK internals and relied on them (Groovy did that a lot), and they simply changed, as they're allowed to. The most disruptive specification change was actually dropping the "1." prefix from the version string, that many codebases used to parse. Starting with JDK 16, Jigsaw is finally being fully turned on, and is starting to block access to internal JDK classes unless the application explicitly allows it. Ultimately, this will force libraries not to rely on internal implementation details and so get themselves tied to a specific version.
  - dcminter 6y ago
    While I remember, here's a good example of an (IMO) bad decision being made due to the LTS meme: https://lists.ubuntu.com/archives/ubuntu-release/2018-February/004275.html https://lists.ubuntu.com/archives/ubuntu-release/2018-Februa... Point taken about the actual underlying causes of the upgrade pain though. Speaking personally I very much appreciate all the work that goes into delivering OpenJDK and I think some of the anti-Java groupthink that exists on HN is regrettable.
    - abraae 6y ago
daniel42__ 6y ago
but whats happens if a feature i use gets deprecated in version 15/16?
- pron 6y ago
  First, commonly used features aren't deprecated frequently. Second, you'd get a warning at least a year in advance (the more important feature -- the longer the warning). BTW, note that when something is removed from mainline, it is no longer maintained in Updates (because there are no more patches to the component to backport), and so it's not supported in "free LTS" offerings. If you want to continue using removed features for a few more years your only option is to buy long-term support.
  - daniel42__ 6y ago
    good point
thom 6y ago
It's a shame that Clojure only 'officially' supports the LTS versions. That is then reflected in what versions libraries and tools support so things seem to regularly break near the bleeding edge.
- pron 6y ago
  The current version isn't the bleeding edge. It's the version most recommended for use in production. The bleeding edge is Early Access release. If things break for new versions, the root cause needs to be found, because this shouldn't happen if libraries target the spec.
  - thom 6y ago
    I feel like the blood is in the eye of the beholder. When I upgrade JVMs and stuff in Emacs’s Clojure ecosystem breaks, that’s painful for me, and so I reflexively avoid doing that.

by pron 6y ago

tyingq 6y ago

Sure, so if I go to adoptopenjdk, the home page offers up 2 LTS versions (8,11) , and "LATEST". Same for Amazon's Corretto. And they all make note of LTS or not. I believe you, but that message isn't front and center on the various OpenJDK distributions.

pron 6y ago
Sadly, while Java is otherwise careful to enforce various standards, anyone is free to call whatever they like LTS. OpenJDK (the source of most JDK distributions) has no concept of LTS (e.g., you'll find no mention of LTS here: https://openjdk.java.net/projects/jdk/11/ https://openjdk.java.net/projects/jdk/11/). Different vendors can call LTS whatever they like, and what that actually entails depends on the vendor. If we define LTS to at least include long-term maintenance in the form of bug and security fixes of the entire JDK, then no one offers a free LTS. Free offerings that call themselves LTS are just builds of the OpenJDK Updates project, that backports fixes from mainline, and so only includes fixes for the intersection of the old version and the current one (i.e. no "free LTS" offers patches for, say, CMS or Nashorn, and multiple other components that exist in 11 or 8 but not in 16). "Free LTS" offerings are only recommended for legacy hobby projects. Important production software should use either the current version (free) or buy an LTS service for an old version from some trusted vendor. The only version that is fully and freely maintained is the current one, and it also offers the cheapest upgrade process and the best performance. Don't think that if the vendor calls something LTS and ships updates that include some fixes you're actually getting some fully-maintained JDK. BTW, AdoptOpenJDK is not affiliated or involved with OpenJDK, and is made by an IBM team that is exceptionally uninvolved and unfamiliar with OpenJDK compared to all other OpenJDK distributions (Oracle, Red Hat, SAP, Azul, Bellsoft, and Amazon).
- scns 6y ago
  Hm, my impression is that usually OpenJDK 8 is the fastest: https://www.phoronix.com/scan.php?page=article&item=openjdk-14-benchmark&num=5 https://www.phoronix.com/scan.php?page=article&item=openjdk-... https://www.phoronix.com/scan.php?page=article&item=graalvm201-openj920-jvm&num=5 https://www.phoronix.com/scan.php?page=article&item=graalvm2... (edit: added missing version (slighly embarassed) and second link)
  - pron 6y ago
    It's definitely the slowest, and by pretty significant margins. Those tests did, however, uncover bad default settings in JDK 14 on some machine sizes, which happened to be those Phoronix ran their benchmarks on: https://kstefanj.github.io/2020/04/16/g1-ootb-performance.html https://kstefanj.github.io/2020/04/16/g1-ootb-performance.ht... Those bad defaults are fixed in 15. Moving away from 8 results in a significant saving in hardware/hosting costs for the vast majority of large applications.
cesarb 6y ago
Linux distributions too, they all seem to offer three Java packages: one for Java 8, one for Java 11, and one for Java "latest". The default is either the Java 8 one or the Java 11 one.

dcminter 6y ago

I've seen a reluctance to move from Java 8 because of the issues upgrading past Jigsaw (e.g. the build I'm working on today bleeds warnings about groovy doing illegal reflective access - and that's just a cosmetic issue) and so many shops decided to wait until the "LTS" Java 11 came along to make the jump. Now that they're there and with the memory of the upgrade pain there's reluctance to upgrade again before Java 17. I think once they do that and see a much more normal upgrade path for that leap they'll be a lot more willing to track all the releases and not just the LTS ones (real or not it's perceived as being a thing).

pron 6y ago
I agree. Funnily enough, though, the upgrade pain to 9+ had nothing to do with Jigsaw, because its encapsulation hasn't even been turned on (unless you count warnings). It was just the biggest and most visible change, so people blamed their unrelated upgrade issues on it. The actual cause for many issues was that some popular libraries hacked into off-specification, undocumented JDK internals and relied on them (Groovy did that a lot), and they simply changed, as they're allowed to. The most disruptive specification change was actually dropping the "1." prefix from the version string, that many codebases used to parse. Starting with JDK 16, Jigsaw is finally being fully turned on, and is starting to block access to internal JDK classes unless the application explicitly allows it. Ultimately, this will force libraries not to rely on internal implementation details and so get themselves tied to a specific version.
- dcminter 6y ago
  While I remember, here's a good example of an (IMO) bad decision being made due to the LTS meme: https://lists.ubuntu.com/archives/ubuntu-release/2018-February/004275.html https://lists.ubuntu.com/archives/ubuntu-release/2018-Februa... Point taken about the actual underlying causes of the upgrade pain though. Speaking personally I very much appreciate all the work that goes into delivering OpenJDK and I think some of the anti-Java groupthink that exists on HN is regrettable.
  - abraae 6y ago

daniel42__ 6y ago

but whats happens if a feature i use gets deprecated in version 15/16?

pron 6y ago
First, commonly used features aren't deprecated frequently. Second, you'd get a warning at least a year in advance (the more important feature -- the longer the warning). BTW, note that when something is removed from mainline, it is no longer maintained in Updates (because there are no more patches to the component to backport), and so it's not supported in "free LTS" offerings. If you want to continue using removed features for a few more years your only option is to buy long-term support.
- daniel42__ 6y ago
  good point

thom 6y ago

It's a shame that Clojure only 'officially' supports the LTS versions. That is then reflected in what versions libraries and tools support so things seem to regularly break near the bleeding edge.

pron 6y ago
The current version isn't the bleeding edge. It's the version most recommended for use in production. The bleeding edge is Early Access release. If things break for new versions, the root cause needs to be found, because this shouldn't happen if libraries target the spec.
- thom 6y ago
  I feel like the blood is in the eye of the beholder. When I upgrade JVMs and stuff in Emacs’s Clojure ecosystem breaks, that’s painful for me, and so I reflexively avoid doing that.