3 ms·

The JEP says you'll be able to use Unsafe at least until JDK 25. There's surely enough time for libraries to migrate away from unsafe by the time a significant

by pron 3y ago

The JEP says you'll be able to use Unsafe at least until JDK 25. There's surely enough time for libraries to migrate away from unsafe by the time a significant number of the ecosystem is on 25. I don't see why this should have any impact at all on adopting 17 or 21, which are unaffected.

pjmlp 3y ago
I hope the current state of large organizations staying in Java 8 as long as they can to avoid dealing with modules, is somehow a lesson for how to deliver this change. Two months ago I did a fresh deploy of Java 8 in production for a SaaS solution, exactly because that is what the product and support team care about.
- 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.

by pron 3y ago

pjmlp 3y ago

I hope the current state of large organizations staying in Java 8 as long as they can to avoid dealing with modules, is somehow a lesson for how to deliver this change. Two months ago I did a fresh deploy of Java 8 in production for a SaaS solution, exactly because that is what the product and support team care about.

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.