Hacker News Reader

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.

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

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.

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

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

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.

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

> add-opens [...] is absolutely essential for Java's security (it is impossible for any Java code to make any strong guarantees without it

How do you figure? What kinds of guarantees?

> to prevent the kind of problems we've seen when migrating from 8 to 9

But it only prevented it from happening later by making it happen now! There's a good chance that most of the programs broken by modules would never have broken otherwise.

> How do you figure? What kinds of guarantees?

Any, but specifically around security (almost all security is provided by certain preconditions being met, namely that method foo() is called only immediately after ensuring that method bar() returns true, or that an object of type Baz is always initialised in a certain way.

Prior to modules, the meaning of any line of Java code anywhere -- including in the JDK itself -- was subject to change by any other line of code in any loaded library through various kinds of monkey patching. You could not guarantee anything. With modules, if `foo` is private, and the only call to it is in `if (bar()) foo();` you can guarantee that foo is only called when bar is true.

Now, strong encapsulation isn't airtight yet, and there are still some loopholes left to let straggler libraries catch up or because there aren't replacements to some unsafe operations yet, but it will be very soon.

> There's a good chance that most of the programs broken by modules would never have broken otherwise.

First, almost all problems migrating to 9+ were because of such non-portable code, and the disruption was quite significant, and the rate of internal change is increasing. Second, this makes it happen now instead of happening, perhaps on a smaller scale, at each and every release for the next decades.

> Any, but specifically around security

Ah, so they had to add it because they plan on removing the security manager API. So it is a breaking change for the sake of another breaking change.

The Security Manager API hasn't been an important Java security feature for many years. It was a security feature for Applets, and over the past decade it's been used by a few applications mostly for monitoring/toy sandboxing. In any event, a vanishingly small number of applications use it. Strong encapsulation is part of a long-term effort to make Java more secure, as threats are changing.

Also, encapsulation isn't a breaking change. Java's strong backward compatibility commitment is with respect to the Java SE specification. No APIs are affected. It's only internal classes that have always been subject to change, and with clear warnings that they must not be accessed, that are encapsulated.

Are Python, Ruby, and Lua all inherently insecure? Why do so many programs that care about security use them? They all allow monkey patching, after all.

Obviously, Java is used for much more critical applications than Python, Ruby, or Lua, but I don't know enough about their security strategy. Just as Java's performance is constantly being improved, so does its security.

What language besides Java has a "feature" that requires a whitelist to use reflection, that you can't just say "everything" for? Or is Java the only secure programming language that exists?

Strong encapsulation isn'y a whitelist for reflection. It forbids the turning off of access control by arbitrary libraries (you do know that even before modules you had to explicitly setAccessible if you wanted to break through access control) -- unless the application explicitly allows it. Some languages don't have reflection at all, and among those that do, Java is clearly the language that is by far most popular for serious business-critical applications.

> you do know that even before modules you had to explicitly setAccessible if you wanted to break through access control

Yes, I do know that, and I'm fine with it. If it still worked then I wouldn't mind modules. My complaint in particular is that a command line whitelist is needed for setAccessible to work anymore.

Right, but the command-line is intentional: it is intended to make the application aware of potential maintenance and/or security issues, and setAccessible is really a potential maintenance and/or security issue. The only argument against it would be the desire to allow libraries to impose such risks on applications without the application knowing about it. I understand why some library authors would not like their users to know their libraries pose such a risk, but obviously the applications should take precedence.

My issue isn't that it needs a command line parameter. It's that you need to create a whitelist that enumerates everything that anything is going to use individually. I'd be fine with modules if --add-opens had a "let this module reflectively access everything" wildcard, or if --illegal-access=permit were never removed.

But that wouldn't express what the potential issue is. You want to know that internal changes in which modules could break you, and/or in what way you're expanding the security attack surface area. Such a library needs to tell you what "bad" things it does and give you a list of modules whose encapsulation in breaks open that you could put on the command line.

At any moment, Oracle could change the package names of all internal code from `com.sun` to `com.oracle` or to have a randomized prefix, which would break all those programs as well.

They could, sure, but that would again be a breaking change for the sake of being a breaking change. Also, maybe since those "nonportable" things are so widely used, Oracle should just add them to the API officially.

Java's backward compatibility applies only to the spec, i.e. the API. If any change to any method in the ~6M MLOC standard library is a "breaking change," then nothing all changes are "breaking changes," and it doesn't matter if there's good reason for them or not; we want things to not break, so internal code needs to be encapsulated. As to the last remaining popular "non-API-APIs", which is mostly just Unsafe, it is, indeed not encapsulated, and over time it will be shrunk only as replacement APIs are available.

I migrated personally (or overseen migration) of many projects from Java 8 (and even Java 6) to Java 11.

Modules in Java 9 were a bit controversial back then, so I guess that's the reason we hear a lot about it, but I haven't encountered an issue related to modules even once.

Most of the migration work that was needed was just upgrading libraries, or adding new dependencies for Java EE APIs that moved out of the JDK.

And why libraries were incompatible? Relying on undocumented internals is one thing, but the funny thing is that a surprisingly large number of libraries broke because they relied on the format of the Java version string. When it changed from 1.8 to 9.0, they suddenly saw a "Java Version 0" and didn't know what to do with it.

> When it changed from 1.8 to 9.0, they suddenly saw a "Java Version 0" and didn't know what to do with it.

That's true. That change was probably the biggest single "breaking change" in that release.

I would go the other way around - it's entirely Oracle's fault for trying to be too compatible with unfortunate mistakes made in the past. Java Serialization is the root of all these things, and should have been deprecated and more safeguards should have been added. Perhaps even an equivalent of --add-opens for which classes are safe to serialize!

This would certainly have broken a large number of software, but it's the right way to go. Whichever way you define the "compatibility promise", I think security overrides that.

At least it looks like Oracle is going this way[1], I just wish that it would have been sooner.

[1] https://inside.java/2019/11/07/whywehateserialization/

The log4j exploit was based on remote class loading, not serialization... though if your JVM protected you against remote class loading, it's indeed correct that one way to bypass that protection was by using a serialization attack.

It has been proven that if platforms don't ramm through, their users will keep using the old ways as long as they can.

Where has this been proven? And what's wrong with using the old ways?

Windows XP, Java 8, Python 2, C++98,CLI apps like pre 1980's,..., plenty of examples.

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

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.

So the parent poster was in fact wrong about Minecraft using Java 8.

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.

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

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.

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

With OpenJDK, do companies still license Java?

OpenJDK is GPL-2 + linking exception; Similar to LGPL. Dunno what that other guy is talking about.

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?

Maybe there were some, mainly because people don't read and rather rely on tweeter feeds from urban myths.

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

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

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

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.

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