8 ms·

Omg it is java16 already and the whole world is still on java8

by AzzieElbab 6y ago

TravelPiglet 6y ago
Java 11 is the current LTS and seems to finally be somewhat stable.
tyingq 6y ago
To be fair, the chain is Java 8, Java 11, Java 17 (TBA) if you only consider LTS versions.
- oweiler 6y ago
  There is no reason to use the LTS versions.
- 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.
  - 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.
pjmlp 6y ago
A marketing trick that Google takes advantage of when selling Kotlin to Android devs unaware of the real Java ecosystem.
- EE84M3i 6y ago
  Could you clarify? What's the relation between Kotlin and Java 8 and/or Google?
  - blandflakes 6y ago
    I think the thrust is that Google would happily convince everybody that the whole world is on Java 8, because that would make both the stalled version of Java on Android look less dated, and further Kotlin a much more modern language than the Java you can get anywhere (I'm not sure how "direct" Google's benefit from Kotlin adoption is... it certainly makes it more respectable as the primary Android lang). The truth is more like - Kotlin is a much more modern language that the version of Java available on Android, but the gap between Kotlin and any of the previous 2 LTS Java versions is way smaller. Kotlin is pretty pleasant, though, IMO.
    - pjmlp 6y ago
      More or less it. They use Android Java samples on their Java vs Kotlin talks on why Kotlin. Then not only is Android Java a cherry picked subset of Java 8, the features they are adding support up to Java 11 are mostly related to standard library, and not all of them. Then there is the feeling of anti-Java culture in Android, with #KotlinFirst, despite the fact of Android Studio, Android Frameworks, Gradle being Java based. The irony is that they don't get that as Java and JVM moves forward, Kotlin will eventually be forced to differentiate between JVM and ART worlds.
      - blandflakes 6y ago
        My take agreeing with this was not well-received elsewhere: https://news.ycombinator.com/item?id=26009804 https://news.ycombinator.com/item?id=26009804 I did a lot of Java on Android, and it was not representative of the Java I do on the serverside.
kasperni 6y ago
Meanwhile the Python ecosystem is still trying to get rid of Python 2. Python 3 was released in 2008. The successor to Java 8 (Java 9) was released in 2017.

Omg it is java16 already and the whole world is still on java8

TravelPiglet 6y ago

Java 11 is the current LTS and seems to finally be somewhat stable.

tyingq 6y ago

To be fair, the chain is Java 8, Java 11, Java 17 (TBA) if you only consider LTS versions.

oweiler 6y ago
There is no reason to use the LTS versions.
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.
- 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.

pjmlp 6y ago

A marketing trick that Google takes advantage of when selling Kotlin to Android devs unaware of the real Java ecosystem.

EE84M3i 6y ago
Could you clarify? What's the relation between Kotlin and Java 8 and/or Google?
- blandflakes 6y ago
  I think the thrust is that Google would happily convince everybody that the whole world is on Java 8, because that would make both the stalled version of Java on Android look less dated, and further Kotlin a much more modern language than the Java you can get anywhere (I'm not sure how "direct" Google's benefit from Kotlin adoption is... it certainly makes it more respectable as the primary Android lang). The truth is more like - Kotlin is a much more modern language that the version of Java available on Android, but the gap between Kotlin and any of the previous 2 LTS Java versions is way smaller. Kotlin is pretty pleasant, though, IMO.
  - pjmlp 6y ago
    More or less it. They use Android Java samples on their Java vs Kotlin talks on why Kotlin. Then not only is Android Java a cherry picked subset of Java 8, the features they are adding support up to Java 11 are mostly related to standard library, and not all of them. Then there is the feeling of anti-Java culture in Android, with #KotlinFirst, despite the fact of Android Studio, Android Frameworks, Gradle being Java based. The irony is that they don't get that as Java and JVM moves forward, Kotlin will eventually be forced to differentiate between JVM and ART worlds.
    - blandflakes 6y ago
      My take agreeing with this was not well-received elsewhere: https://news.ycombinator.com/item?id=26009804 https://news.ycombinator.com/item?id=26009804 I did a lot of Java on Android, and it was not representative of the Java I do on the serverside.

kasperni 6y ago

Meanwhile the Python ecosystem is still trying to get rid of Python 2. Python 3 was released in 2008. The successor to Java 8 (Java 9) was released in 2017.