10 ms·

It's a big deal because most large users of Java aren't actually using the newer versions. It's very hard to source that claim, and I apologize for the lack of

It's a big deal because most large users of Java aren't actually using the newer versions. It's very hard to source that claim, and I apologize for the lack of hard data, but in my experience with "enterprise Java", it's almost all still Java 11, or even Java 8. Some lame anecdotes: Minecraft ships with a bundled version of Java 8. Most linux distributions still default to Java 11, and you have to explicitly ask for newer JDKs. Some distributions, like Void Linux, still only package Java 11. Many enterprise applications don't even use the system Java environments, and package their own outdated version of Java, sometimes in /opt, sometimes in their installation directory on Windows. (edit: to this point, Minecraft apparently ships with 1.8.0_51 from 2015, and I'm sure I've seen similar with some Java applications at work. I imagine for programs that aren't servers listening on the network, the threat of exploitation seemed lower, and there was less of an (perceived) need to update even the version of Java. If it ain't broke, don't fix it, and all that.) Regardless of the fact people should upgrade to newer Java versions, the reality is (IME) they ... haven't. And so many (very large!) corporations are relying on vulnerable versions of Java, which is why this is such a big deal.

severino 5y ago
The reason that most distributions only packaged Java 11 until recently is actually very simple: it was the current "LTS" version, which had a longer support window. So companies won't usually jump into Java 12, or 13... because it meant you had 6 months until that release would be considered unsupported. That's why Java 11 has been receiving updates (latest one, 11.0.13, dates from October 2021) while Java 12, for example, got its last release (12.0.2) in 2019. Now that Java 17 (released two months ago) is the new Java LTS version, you could expect most distributions to package it. For example, Ubuntu has been offering Java 17 for a couple of months.
- spijdar 5y ago
  Sure, and it's supported by more software than the newer versions (edit: because this wasn't clear, I mean I think the default JDK will remain 11 for a while, even on distros that package newer), which have been making a fair number of backwards incompatible changes, which seems to have had the effect of discouraging adoption of newer Java versions. I'm not a Java developer, so I don't really have personal experience or frustration with it, but it seems like I read "x was deprecated, then dropped, in versions <x>, <y> of Java" a lot, changes that would require pretty sweeping changes to codebases that relied on the old behavior/features. A lot are still stuck on 8, and aren't even compatible with 11, much less 15 or 17. I think VMWare's vCenter software still uses Java 8 internally...
  - ta45674754 5y ago
    Yeah that's the biggest problem, a complex web of dependencies on old legacy applications built using JDK 8/11, not so much any language changes. Sometimes there's just no options to upgrade e.g. companies stuck on Oracle 12, can only use Flyway 5.1.4 etc, so that counts out Spring 2.5.x and so on and so on. Many libraries will eventually drop support for older JREs, and then you're left with a big bang approach and having to upgrade everything to the latest version, and that may include changes in the servlet/REST/etc specs, which can be a bit overwhelming for large legacy codebases. Its why tools like Dependabot are so important imo, they keep you up-to-date in incremental steps if you're vigilant, rather than have the POM/build.gradle ossify over time.
MomoXenosaga 5y ago
But then whose fault is it? Software will always be compromised sooner or later by hackers looking for exploits. I know Microsoft just threw the keyboard at the wall and said "fuck it everyone gets forced to update".
- deleted 5y ago
  [deleted]
hugi 5y ago
I think the most recent Minecraft release (1.18) actually requires Java 17?
- tehbeard 5y ago
  They've only recently been bumping Java versions. For the longest time, it was 6, then 8, and it stayed on 8 for years. Iirc 1.17 was a jump to Java 16 after a lot of internal reworking, and I guess with Java 17 being LTS, thats why they've moved to that.
  - hugi 5y ago
    So the parent poster was in fact wrong about Minecraft using Java 8.
    - 63 5y ago
      Not really. Only the two most recent major versions of Minecraft use Java 16/17. A lot, possibly most, of the online community still plays on old versions 1.8.9 and 1.12.2 which use Java 8.
      - mantaraygun 5y ago
        > 1.8.9 and 1.12.2 Correct me if I'm wrong, but isn't the first favored by pay-to-win servers and pvp specializing servers, while 1.12.2 is favored for modding? Both seem pretty niche to me, albeit noisy niches. There have been several substantial updates to the game since 1.12 and I'm quite sure most players are presently on 1.18 or at least 1.17. And I don't have much sympathy for the plight of those P2W servers.
        salawat 5y ago
        1.14.4 works just fine on jdk 1.8, modded or otherwise. I know this, because I helped get it running properly with Forge integration on Raspberry Pi, and am working on building out an Aarch64 base Linux image for more recent versions to leverage the 8GB version of the Pi for maybe supporting a mod or two. Someone else may have done it already, but it's more an exercise in cross-compiling for me. The lack of a 64 bit JDK build was the big blocker a couple years ago. Haven't checked back to see if Raspbian or anyone else got around to it. I can second that modules were a way bigger deal than people here seem to be willing to admit to. I avoided 9+ like the plague because redefining one of your base visibility modifiers and the inevitable charlie-foxtrot that would entail, plus Oracles license shenanigans was just not something I was willing to wade through.
matwood 5y ago
According to the original RCE post: > JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. So people just need to stay up to date on the latest patch version. Latest 8x is 8u312 and 11x is 11.0.13. So Java 11 and 8 have some mitigation already in place, but people need to be applying patches like they should for all other critical system software.
pjc50 5y ago
At one point Oracle changed the licensing, which caused enterprises to stop upgrading.
- pjmlp 5y ago
  Maybe there were some, mainly because people don't read and rather rely on tweeter feeds from urban myths.
- kupopuffs 5y ago
  With OpenJDK, do companies still license Java?
  - NavinF 5y ago
    OpenJDK is GPL-2 + linking exception; Similar to LGPL. Dunno what that other guy is talking about.
- alanfranz 5y ago
  So, the root of all problems is that companies don’t want to pay, not even when professional, paid support is available. Why complain, then?
josephcsible 5y ago
> in my experience with "enterprise Java", it's almost all still Java 11, or even Java 8. IMO, this is entirely Oracle's fault, for ramming through modules and --add-opens requirements starting in Java 9 that broke almost everything for no good reason.
- pron 5y ago
  add-opens was only required starting in 17, and modules, whose encapsulation wasn't even on by default until JDK 16, had little if anything to do with the migration issues from 8 to 9. They just happened to be 9's most famous feature, so they got the blame. Nearly all migration issues were due to libraries bypassing the Java spec in 8 and relying on internal implementation details, essentially becoming intentionally non-portable. Some of them had a good reason to do so, but nevertheless, that's what happened. Java 9 was one of the biggest Java releases ever, internal implementation details changed all over the JDK, so many libraries that had become tied to 8 broke. Now upgrading is no longer too big a deal because all popular libraries have long been fixed. Modules, however, are related to those issues in that now when their encapsulation has finally been turned on (in 16 and 17), they will do their job of preventing this problem of bypassing the spec from recurring (the application is able to grant internal access to a library, but at least it knows there might be a potential maintenance and/or security issue to keep an eye on when it does).
  - josephcsible 5y ago
    My complaint about the --add-opens fiasco is that it was basically a breaking change for the sake of being a breaking change, rather than one that was necessary to fix some bug or add some feature. > they will do their job of preventing this problem of bypassing the spec from recurring This feels like curing cancer by killing the patient.
    - pron 5y ago
      > My complaint about the --add-opens fiasco is that it was basically a breaking change for the sake of being a breaking change, rather than one that was necessary to fix some bug or add some feature. add-opens, which, again, has been required only since JDK 17, is absolutely essential for Java's security (it is impossible for any Java code to make any strong guarantees without it), and to prevent the kind of problems we've seen when migrating from 8 to 9. The only thing it breaks is the ability to write non-portable libraries without the application knowing about it. There is not a single line of code that would be affected by it that wouldn't have also been susceptible to any change in internal details, which can happen in any release without warning. Since the rate of internal implementation details is only going to grow with the growing investment in Java, this change helps warn against potential issues due to non-portable code. > This feels like curing cancer by killing the patient. JDK 17 adoption is pretty impressive (and faster than 11's). Doesn't seem like the patient is dead.
callmeal 5y ago
>It's a big deal because most large users of Java aren't actually using the newer versions. It's very hard to source that claim, and I apologize for the lack of hard data, but in my experience with "enterprise Java", it's almost all still Java 11, or even Java 8. It should still not be a big deal, because there are mitigations in place for Java 11 and Java 8 - just upgrade to the latest patch revision: 11.0.2 and 1.8.0_192 or later exactly like an operating system security patch. Right now, it just feels like a big deal because everyone likes to pile on Java.
- technion 5y ago
  Regrettably I have multiple products, such as pos software from Oracle, that break on minor point release java updates.
karianna 5y ago
Minecraft ships with the latest 17.0.1 now (I run Java at MSFT, we supply their bits )

severino 5y ago

The reason that most distributions only packaged Java 11 until recently is actually very simple: it was the current "LTS" version, which had a longer support window. So companies won't usually jump into Java 12, or 13... because it meant you had 6 months until that release would be considered unsupported. That's why Java 11 has been receiving updates (latest one, 11.0.13, dates from October 2021) while Java 12, for example, got its last release (12.0.2) in 2019. Now that Java 17 (released two months ago) is the new Java LTS version, you could expect most distributions to package it. For example, Ubuntu has been offering Java 17 for a couple of months.

spijdar 5y ago
Sure, and it's supported by more software than the newer versions (edit: because this wasn't clear, I mean I think the default JDK will remain 11 for a while, even on distros that package newer), which have been making a fair number of backwards incompatible changes, which seems to have had the effect of discouraging adoption of newer Java versions. I'm not a Java developer, so I don't really have personal experience or frustration with it, but it seems like I read "x was deprecated, then dropped, in versions <x>, <y> of Java" a lot, changes that would require pretty sweeping changes to codebases that relied on the old behavior/features. A lot are still stuck on 8, and aren't even compatible with 11, much less 15 or 17. I think VMWare's vCenter software still uses Java 8 internally...
- ta45674754 5y ago
  Yeah that's the biggest problem, a complex web of dependencies on old legacy applications built using JDK 8/11, not so much any language changes. Sometimes there's just no options to upgrade e.g. companies stuck on Oracle 12, can only use Flyway 5.1.4 etc, so that counts out Spring 2.5.x and so on and so on. Many libraries will eventually drop support for older JREs, and then you're left with a big bang approach and having to upgrade everything to the latest version, and that may include changes in the servlet/REST/etc specs, which can be a bit overwhelming for large legacy codebases. Its why tools like Dependabot are so important imo, they keep you up-to-date in incremental steps if you're vigilant, rather than have the POM/build.gradle ossify over time.

MomoXenosaga 5y ago

But then whose fault is it? Software will always be compromised sooner or later by hackers looking for exploits. I know Microsoft just threw the keyboard at the wall and said "fuck it everyone gets forced to update".

deleted 5y ago
[deleted]

hugi 5y ago

I think the most recent Minecraft release (1.18) actually requires Java 17?

tehbeard 5y ago
They've only recently been bumping Java versions. For the longest time, it was 6, then 8, and it stayed on 8 for years. Iirc 1.17 was a jump to Java 16 after a lot of internal reworking, and I guess with Java 17 being LTS, thats why they've moved to that.
- hugi 5y ago
  So the parent poster was in fact wrong about Minecraft using Java 8.
  - 63 5y ago
    Not really. Only the two most recent major versions of Minecraft use Java 16/17. A lot, possibly most, of the online community still plays on old versions 1.8.9 and 1.12.2 which use Java 8.
    - mantaraygun 5y ago
      > 1.8.9 and 1.12.2 Correct me if I'm wrong, but isn't the first favored by pay-to-win servers and pvp specializing servers, while 1.12.2 is favored for modding? Both seem pretty niche to me, albeit noisy niches. There have been several substantial updates to the game since 1.12 and I'm quite sure most players are presently on 1.18 or at least 1.17. And I don't have much sympathy for the plight of those P2W servers.
      - salawat 5y ago
        1.14.4 works just fine on jdk 1.8, modded or otherwise. I know this, because I helped get it running properly with Forge integration on Raspberry Pi, and am working on building out an Aarch64 base Linux image for more recent versions to leverage the 8GB version of the Pi for maybe supporting a mod or two. Someone else may have done it already, but it's more an exercise in cross-compiling for me. The lack of a 64 bit JDK build was the big blocker a couple years ago. Haven't checked back to see if Raspbian or anyone else got around to it. I can second that modules were a way bigger deal than people here seem to be willing to admit to. I avoided 9+ like the plague because redefining one of your base visibility modifiers and the inevitable charlie-foxtrot that would entail, plus Oracles license shenanigans was just not something I was willing to wade through.

matwood 5y ago

According to the original RCE post: > JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. So people just need to stay up to date on the latest patch version. Latest 8x is 8u312 and 11x is 11.0.13. So Java 11 and 8 have some mitigation already in place, but people need to be applying patches like they should for all other critical system software.

pjc50 5y ago

At one point Oracle changed the licensing, which caused enterprises to stop upgrading.

pjmlp 5y ago
Maybe there were some, mainly because people don't read and rather rely on tweeter feeds from urban myths.
kupopuffs 5y ago
With OpenJDK, do companies still license Java?
- NavinF 5y ago
  OpenJDK is GPL-2 + linking exception; Similar to LGPL. Dunno what that other guy is talking about.
alanfranz 5y ago
So, the root of all problems is that companies don’t want to pay, not even when professional, paid support is available. Why complain, then?

josephcsible 5y ago

> in my experience with "enterprise Java", it's almost all still Java 11, or even Java 8. IMO, this is entirely Oracle's fault, for ramming through modules and --add-opens requirements starting in Java 9 that broke almost everything for no good reason.

pron 5y ago
add-opens was only required starting in 17, and modules, whose encapsulation wasn't even on by default until JDK 16, had little if anything to do with the migration issues from 8 to 9. They just happened to be 9's most famous feature, so they got the blame. Nearly all migration issues were due to libraries bypassing the Java spec in 8 and relying on internal implementation details, essentially becoming intentionally non-portable. Some of them had a good reason to do so, but nevertheless, that's what happened. Java 9 was one of the biggest Java releases ever, internal implementation details changed all over the JDK, so many libraries that had become tied to 8 broke. Now upgrading is no longer too big a deal because all popular libraries have long been fixed. Modules, however, are related to those issues in that now when their encapsulation has finally been turned on (in 16 and 17), they will do their job of preventing this problem of bypassing the spec from recurring (the application is able to grant internal access to a library, but at least it knows there might be a potential maintenance and/or security issue to keep an eye on when it does).
- josephcsible 5y ago
  My complaint about the --add-opens fiasco is that it was basically a breaking change for the sake of being a breaking change, rather than one that was necessary to fix some bug or add some feature. > they will do their job of preventing this problem of bypassing the spec from recurring This feels like curing cancer by killing the patient.
  - pron 5y ago
    > My complaint about the --add-opens fiasco is that it was basically a breaking change for the sake of being a breaking change, rather than one that was necessary to fix some bug or add some feature. add-opens, which, again, has been required only since JDK 17, is absolutely essential for Java's security (it is impossible for any Java code to make any strong guarantees without it), and to prevent the kind of problems we've seen when migrating from 8 to 9. The only thing it breaks is the ability to write non-portable libraries without the application knowing about it. There is not a single line of code that would be affected by it that wouldn't have also been susceptible to any change in internal details, which can happen in any release without warning. Since the rate of internal implementation details is only going to grow with the growing investment in Java, this change helps warn against potential issues due to non-portable code. > This feels like curing cancer by killing the patient. JDK 17 adoption is pretty impressive (and faster than 11's). Doesn't seem like the patient is dead.

callmeal 5y ago

>It's a big deal because most large users of Java aren't actually using the newer versions. It's very hard to source that claim, and I apologize for the lack of hard data, but in my experience with "enterprise Java", it's almost all still Java 11, or even Java 8. It should still not be a big deal, because there are mitigations in place for Java 11 and Java 8 - just upgrade to the latest patch revision: 11.0.2 and 1.8.0_192 or later exactly like an operating system security patch. Right now, it just feels like a big deal because everyone likes to pile on Java.

technion 5y ago
Regrettably I have multiple products, such as pos software from Oracle, that break on minor point release java updates.

karianna 5y ago

Minecraft ships with the latest 17.0.1 now (I run Java at MSFT, we supply their bits )