3 ms·

No. JDK9/JDK11's adoption issues were due to --add-opens/--add-exports and the JDK developers hostile approach towards reflection. It's an obsession over "pure

No. JDK9/JDK11's adoption issues were due to --add-opens/--add-exports and the JDK developers hostile approach towards reflection. It's an obsession over "pure" code that has no basis in reality. I'm sorry: Applets don't exist anymore, this obsession is outdated and futile. There is no rational justification behind breaking compatibility with almost every large Java project in existence to the extent that https://java.com https://java.com still downloads Java 8.

pron 3y ago
> No. JDK9/JDK11's adoption issues were due to --add-opens/--add-exports and the JDK developers hostile approach towards reflection. No. JDK 9 and 11 kept all default accessibility the same as in JDK 8 (all you got was a warning) until it was changed in JDK 16: https://openjdk.org/jeps/396 https://openjdk.org/jeps/396 The adoption issues were almost entirely due to non-portable libraries depending on internal implementation details that had changed in 9. Some were due to changes like that to the version string that dropped the "1." prefix for the first time. > It's an obsession over "pure" code that has no basis in reality. I'm sorry: Applets don't exist anymore, this obsession is outdated and futile. I don't understand the relationship to Applets, but the emphasis on integrity (a generalisation of safety) is all around the software world. It's the main reason for Rust's existence. > to the extent that https://java.com https://java.com still downloads Java 8. That's because java.com is a website for end users downloading the JRE, which was discontinued after 8 (really in 11).
- iscoelho 3y ago
  > No. JDK 9 and 11 kept all default accessibility the same as in JDK 8 (all you got was a warning) until it was changed in JDK 16: https://openjdk.org/jeps/396 https://openjdk.org/jeps/396 This is simply not true. This sounds like gaslighting in an attempt to rewrite history, which IMHO shows poor credibility from the JDK developers. > I don't understand the relationship to Applets, but the emphasis on integrity (a generalisation of safety) is all around the software world. It's the main reason for Rust's existence. Yes, and Rust has "unsafe". Java still has JNI. If programmers want to write unsafe code, they will write it, to the point of shipping a modified JVM. It's their computers. It's their code. It is a misguided and fruitless effort to push ideology on them. > That's because java.com is a website for end users downloading the JRE, which was discontinued after 8 (really in 11). I don't buy this.
  - pron 3y ago
    > This is simply not true. This sounds like gaslighting in an attempt to rewrite history, which IMHO shows poor credibility from the JDK developers. I'm sorry, but default access was not changed until JDK 16. Here's the relevant section from JDK 9's JEP 261 (https://openjdk.org/jeps/261#Relaxed-strong-encapsulation https://openjdk.org/jeps/261#Relaxed-strong-encapsulation): In this release the strong encapsulation of some of the JDK's packages is relaxed by default... --illegal-access=permit opens each package in each module in the run-time image to code in all unnamed modules, i.e., to code on the class path, if that package existed in JDK 8. This enables both static access, i.e., by compiled bytecode, and deep reflective access, via the platform's various reflection APIs... This mode is the default in JDK 9. > Yes, and Rust has "unsafe". Java still has JNI. If programmers want to write unsafe code, they will write it, to the point of shipping a modified JVM. It's their computers. It's their code. It is a misguided and fruitless effort to push ideology on them. And Java will still gives you access to unsafe operations (even after this change) albeit with a flag that serves a similar purpose to Rust's unsafe, only done better. The goal is not to impose an ideology on programmers. If you read the JEP, the goal is for them, and the runtime, to know which invariants can be trusted and which can't (e.g. the JIT might want to optimise things based on the assumption that strings are final, but using unsafe code or native code makes that untrue). That's why JNI will also require a flag. As it is today, neither the runtime nor the application developer is able to know whether there's some code that could mess about with their assumptions. > I don't buy this. It literally says that on the front page of java.com: "Get Java for desktop applications." OTOH, the developer website, https://dev.java/ https://dev.java/, lets developers download JDKs only, as JREs no longer exist.

pron 3y ago

> No. JDK9/JDK11's adoption issues were due to --add-opens/--add-exports and the JDK developers hostile approach towards reflection. No. JDK 9 and 11 kept all default accessibility the same as in JDK 8 (all you got was a warning) until it was changed in JDK 16: https://openjdk.org/jeps/396 https://openjdk.org/jeps/396 The adoption issues were almost entirely due to non-portable libraries depending on internal implementation details that had changed in 9. Some were due to changes like that to the version string that dropped the "1." prefix for the first time. > It's an obsession over "pure" code that has no basis in reality. I'm sorry: Applets don't exist anymore, this obsession is outdated and futile. I don't understand the relationship to Applets, but the emphasis on integrity (a generalisation of safety) is all around the software world. It's the main reason for Rust's existence. > to the extent that https://java.com https://java.com still downloads Java 8. That's because java.com is a website for end users downloading the JRE, which was discontinued after 8 (really in 11).

iscoelho 3y ago
> No. JDK 9 and 11 kept all default accessibility the same as in JDK 8 (all you got was a warning) until it was changed in JDK 16: https://openjdk.org/jeps/396 https://openjdk.org/jeps/396 This is simply not true. This sounds like gaslighting in an attempt to rewrite history, which IMHO shows poor credibility from the JDK developers. > I don't understand the relationship to Applets, but the emphasis on integrity (a generalisation of safety) is all around the software world. It's the main reason for Rust's existence. Yes, and Rust has "unsafe". Java still has JNI. If programmers want to write unsafe code, they will write it, to the point of shipping a modified JVM. It's their computers. It's their code. It is a misguided and fruitless effort to push ideology on them. > That's because java.com is a website for end users downloading the JRE, which was discontinued after 8 (really in 11). I don't buy this.
- pron 3y ago
  > This is simply not true. This sounds like gaslighting in an attempt to rewrite history, which IMHO shows poor credibility from the JDK developers. I'm sorry, but default access was not changed until JDK 16. Here's the relevant section from JDK 9's JEP 261 (https://openjdk.org/jeps/261#Relaxed-strong-encapsulation https://openjdk.org/jeps/261#Relaxed-strong-encapsulation): In this release the strong encapsulation of some of the JDK's packages is relaxed by default... --illegal-access=permit opens each package in each module in the run-time image to code in all unnamed modules, i.e., to code on the class path, if that package existed in JDK 8. This enables both static access, i.e., by compiled bytecode, and deep reflective access, via the platform's various reflection APIs... This mode is the default in JDK 9. > Yes, and Rust has "unsafe". Java still has JNI. If programmers want to write unsafe code, they will write it, to the point of shipping a modified JVM. It's their computers. It's their code. It is a misguided and fruitless effort to push ideology on them. And Java will still gives you access to unsafe operations (even after this change) albeit with a flag that serves a similar purpose to Rust's unsafe, only done better. The goal is not to impose an ideology on programmers. If you read the JEP, the goal is for them, and the runtime, to know which invariants can be trusted and which can't (e.g. the JIT might want to optimise things based on the assumption that strings are final, but using unsafe code or native code makes that untrue). That's why JNI will also require a flag. As it is today, neither the runtime nor the application developer is able to know whether there's some code that could mess about with their assumptions. > I don't buy this. It literally says that on the front page of java.com: "Get Java for desktop applications." OTOH, the developer website, https://dev.java/ https://dev.java/, lets developers download JDKs only, as JREs no longer exist.