3 ms·

Staying on 8 has nothing to do with "dealing with modules" (JDK 11 had the exact same accessibility as JDK 8; the JDK's encapsulation wasn't turned on until JDK

by pron 3y ago

Staying on 8 has nothing to do with "dealing with modules" (JDK 11 had the exact same accessibility as JDK 8; the JDK's encapsulation wasn't turned on until JDK 16). The reason some need to stay on 8 is because they're using old, non-portable libraries that rely on internals that have since changed. Modularising the JDK has only helped prevent that from reoccurring, and has made version upgrades easier than they've ever been. Not modularising the JDK would not have helped people migrate one iota. The internal changes that broke the old non-portable libraries would still have broken them, only there would have been nothing to prevent this from happening over and over again. Also, there isn't much new code being written for 8, and there's a whole lot more of Java code yet to be written than the non-portable code still on 8. In fact, even most existing projects are no longer on 8. Sure, if you only look at the pain, there has certainly been some. But if you look at the pain compared to the benefit, the lesson is that it's been a great success, especially compared to other languages (or even frameworks) doing similar significant changes. I think the vast majority of those who've upgraded consider it worthwhile (again, comparing cost/benefit). Virtual threads, FFM, and the upcoming Valhalla and Leyden are all things that could not have been done without modularisation, and certainly not without significant internal JDK changes, which would have kept the same people on 8 even if there was some way (doubtful and definitely much more expensive) to achieve that without modularisation. We would have been in a far worse place without it: fewer new features and no end to the problem of migration.

jmaker 3y ago
While I do totally agree on the necessity of the steps you outlined, I have yet to discover a reliable ETA for Valhalla and Leyden, and Panama, it’s been like a carrot on a stick so far. And I do totally realize that certain consistency bounds must be in place to smoothen the future evolution of JDK, yet the chasm is still there and a quite significant one. I’m sure you are aware. There’s so many things going on at the same time to be aware of in Javaland, it’s getting quite tedious to persuade everyone to keep it up and not jump ship, after getting burned by the previous JDK (and Spring) upgrades.
- pron 3y ago
  Panama was delivered in JDK 19 and is final in JDK 23, out this March. We don't give ETAs as people may make business decisions based on them. As a matter of policy, we only announce a targeted JDK within the 6 months prior to its release. > it’s getting quite tedious to persuade everyone to keep it up and not jump ship, after getting burned by the previous JDK (and Spring) upgrades. If nothing else, they should be placated by the fact that upgrades are significantly worse in every other ecosystem.
  - iscoelho 3y ago
    > If nothing else, they should be placated by the fact that upgrades are significantly worse in every other ecosystem. A lot of ecosystems care about their users and care about compatibility. Java is a toxic relationship at this point.
    - pron 3y ago
      I think that Java's record on compatibility is unmatched, and users are extremely happy with all the enhancements we've been delivering, which why Java's popularity remains sky-high. But no product can satisfy everyone forever, and if you're unhappy, we'd like to try and address the issues you have; if we can't, we'd be sad to see you go, but we certainly don't wish to hold you hostage.
      - jmaker 3y ago
        Yes, absolutely, Java’s compatibility story has been stellar. To the point that people got spoiled by it and no longer want to join the more agile release cycle. I’ve experienced folks being more like “oh finally, now I can express myself at least a bit like I got used to with some other language”, so not sure the enhancements you’re mentioning go as far as to put Java apart from its modern day alternatives, at least some of those concepts finally trickled through though. Still, a lot of Java deployments are deliver once, never touch it again, those users would be happy to never upgrade anything. It’s no fun to revalidate the semantics in a large project.
iscoelho 3y ago
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.

by pron 3y ago

jmaker 3y ago

While I do totally agree on the necessity of the steps you outlined, I have yet to discover a reliable ETA for Valhalla and Leyden, and Panama, it’s been like a carrot on a stick so far. And I do totally realize that certain consistency bounds must be in place to smoothen the future evolution of JDK, yet the chasm is still there and a quite significant one. I’m sure you are aware. There’s so many things going on at the same time to be aware of in Javaland, it’s getting quite tedious to persuade everyone to keep it up and not jump ship, after getting burned by the previous JDK (and Spring) upgrades.

pron 3y ago
Panama was delivered in JDK 19 and is final in JDK 23, out this March. We don't give ETAs as people may make business decisions based on them. As a matter of policy, we only announce a targeted JDK within the 6 months prior to its release. > it’s getting quite tedious to persuade everyone to keep it up and not jump ship, after getting burned by the previous JDK (and Spring) upgrades. If nothing else, they should be placated by the fact that upgrades are significantly worse in every other ecosystem.
- iscoelho 3y ago
  > If nothing else, they should be placated by the fact that upgrades are significantly worse in every other ecosystem. A lot of ecosystems care about their users and care about compatibility. Java is a toxic relationship at this point.
  - pron 3y ago
    I think that Java's record on compatibility is unmatched, and users are extremely happy with all the enhancements we've been delivering, which why Java's popularity remains sky-high. But no product can satisfy everyone forever, and if you're unhappy, we'd like to try and address the issues you have; if we can't, we'd be sad to see you go, but we certainly don't wish to hold you hostage.
    - jmaker 3y ago
      Yes, absolutely, Java’s compatibility story has been stellar. To the point that people got spoiled by it and no longer want to join the more agile release cycle. I’ve experienced folks being more like “oh finally, now I can express myself at least a bit like I got used to with some other language”, so not sure the enhancements you’re mentioning go as far as to put Java apart from its modern day alternatives, at least some of those concepts finally trickled through though. Still, a lot of Java deployments are deliver once, never touch it again, those users would be happy to never upgrade anything. It’s no fun to revalidate the semantics in a large project.

iscoelho 3y ago

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.