Hacker News Reader

Comment by josephcsible | Hacker News Reader

Oh no, not more command line flags to allow functionality that always worked before! That same decision with modules and reflection in Java 9 is why so much stuff is stuck on Java 8 still.

View on HN

It has nothing to do with why so stuff is stuck on Java 8. In fact, one of the goals of those flags to prevent that from recurring. 99% of the problems migrating from JDK 8 are due to low level libraries depending on internal implementation details that were never subject to backward compatibility and that changed in JDK 9, which was a huge release (https://openjdk.org/projects/jdk9/). Libraries became intentionally non-portable, and applications didn't know that they were made non-portable by the libraries they were using, often inadvertently (transitive dependencies). Now, whenever a library does something that bypasses the spec, i.e. the portion that's covered by backward compatibility, it cannot do it without the application knowing about it and approving it. An application that sticks to the spec and enjoys Java's compatibility, portability, and safety doesn't need to add any flags.

Developers should understand if a dependency use C bindings. But why bother end users with a command line flag.

Perhaps there is a manifest entry/flag so the command line flag is not required ?

1. Application developers frequently don't know how the libraries they're using work, and often don't even know what libraries they're using because they're transitive dependencies (even a version update of a library can pull in a new transitive dependency). If a library imposes any kind of risk on the application, the application has to acknowledge that it accepts it.

2. The last word is given to the application, and the point is that libraries must not make decisions that have a global impact on behalf of the application. That's why an executable JAR, i.e. an application, can grant such permission in its manifest but library JARs cannot.

See more here: https://openjdk.org/jeps/8305968, https://openjdk.org/jeps/8307341

> an executable JAR, i.e. an application, can grant such permission in its manifest

No it can't. If it would, then the change indeed wouldn't be a problem. Oracle has removed --illegal-access=permit completely, and --add-opens doesn't let you specify wildcards.

The question I answered was about --enable-native-access, not --add-opens. --add-opens indicates an actual problem in the program that has to be fixed, so of course we don't allow wildcards. You can still specify that in the manifest even without wildcards, though.

The point is that they were literally breaking changes for the sake of being breaking changes, rather than for any legitimate need.

That is untrue, which you can tell from the simple fact that lots of stuff broke on JDK 9 even though none of the access control restrictions were turned on yet, while far fewer applications broke in JDK 16 or 17, when we finally turned on the access restrictions by default. That stuff broke because of non-portable libraries shows there was a very legitimate need to stop libraries from making applications non-portable without their consent (and there are other motivations: https://openjdk.org/jeps/8305968).

Reply on news.ycombinator.com