5 ms·

This is completely backwards. The reason we're now able to do this is that Java's access to low-level coding features has improved so much that the vast majorit

by pron 3y ago

This is completely backwards. The reason we're now able to do this is that Java's access to low-level coding features has improved so much that the vast majority of programs using Unsafe are now able to get the same functionality and performance using new supported APIs, and without Unsafe's unsafety. That is a huge improvement. Even the small minority of Unsafe-using programs that will see some performance degradation will still be able to get all of it back — if they feel they absolutely need to even at the expense of safety — by using JDK internals. This is a clear win for low-level coding in Java because today there's no way to tell if a Java program is unsafe as some transitive dependency may be using Unsafe even if it doesn't benefit the program at all. Offering full safety for (nearly) all while still offering maximum performance in special cases is an advantage for Java over other languages.

jmaker 3y ago
As long as the deps haven’t all moved to the JDK without Unsafe, I think the ecosystem is tainted by such deps for the foreseeable future. In case you guys conducted an ecosystem survey, where are we at now? Lots are still running on JDK 1.8, some important deployments are on 1.6 or 1.7, even more are on JDK 11. The transition to JDK 17 has started only recently. How much more hesitant will this make projects to upgrade the JDK? There’s quite some tearing already due to 1.8, 11, and now 17, particularly with Pivotal EOL support for Spring 2.7 release train. I wish we could wait with it till the transition to 17 is complete.
- 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.
- krzyk 3y ago
  What is holding you back with upgrade to 17 or 21? Biggest pain was migrating 8 to 9, after that it is piece of cake.
  - jmaker 3y ago
    The transitive hull of the deps
    - krzyk 3y ago
      Yeah, but you usually want to have up to date deps either way, at least for security purposes.
      - jmaker 3y ago
        Of course, a classical trade-off. That’s why I’m taking time to discuss that here. The cost incurred by upstream updates reshuffling the hull makes it for hard budget and timeline decisions and risk management. That’s why larger projects with many deps prefer stable upstream, both the runtime and the libs. There’s also compliance and certification that come into play in regulated industries. Lots of moving parts to keep track of. I need to know what the upstream vendors are up to so we can plan in advance. With JDK, a big trouble is the push to JDK 17+ now within the ecosystem. Sonar Cloud for example now wants JDK 17+ starting next Monday. But you can’t even build your JDK 11 bound projects with Gradle that runs on JDK 17. You could separate the build stage from the run stage, of course, but that’s not really enough in the end. Same story with Spring. With .NET by contrast, the ecosystem still supports the legacy .NET Framework target and you can still run your antiquated projects. Not the same with Java anymore though. It’s pulling the rug.
        pron 3y ago
        Most Java projects written for JDK 1.2 still run fine, unchanged and without recompilation, on JDK 22, provided that they don't make use of libraries that bypass the spec and reach for internals (or unless they're using discontinued technologies like Applets, although those would still be easy to port). Java's backward compatibility only applies to the spec, not to internal implementation details. Before internals were encapsulated in JDK 16, too many libraries reached for internals, and these non-portable libraries made their client applications non-portable without their knowledge. Those libraries reached for internals to add functionality and to improve performance, but in the process knowingly sacrificed portability but didn't make that tradeoff apparent to consumers. Now that internals are encapsulated, upgrades are easier than they've ever been at any point in Java's history. Unfortunately, some large applications that depend on non-portable libraries — some of which were since abandoned — are stuck, but support for JDK 8 continues at lest until 2030.
pjmlp 3y ago
Even the JEP admits that there will be performance costs, which the team hopes won't matter for most use cases, hoping has never been a solution for anything.
- pron 3y ago
  You're defining "hope" as anything short of absolute certainty, so the same could be said about every significant new feature. Because we can never know with absolute certainty what impact it will have until it's seen some significant duration of use in the field, all we ever have is "hope" (guided by experience) that the benefit will have been worth the cost. Since our record is pretty good, I think, I don't see any more reason for concern in this case than in all others (not that that's ever stopped some people from expressing grave concern with pretty much every significant thing we do). In fact, why limit ourselves to technology? The same goes for deciding to make any change in anything. Every intentional change has only ever happened because someone had bet, without absolute certainty, that it will make things better. So you could say that "hope" is the only thing that has ever made anything better (or worse, I guess, if you're a glass-half-empty kinda guy).
  - iscoelho 3y ago
    This is a false premise. We know today how performance will be affected by this. Java developers didn't just start using Unsafe for fun. They use Unsafe because they benchmarked, measured, and found a real performance gain. There is no reason to make this change besides misguided ideology. There is zero benefit.
    - pron 3y ago
      > We know today how performance will be affected by this. We know that a small subset of Unsafe-using code will have to continue using internals to keep performance and won't be able to use the supported APIs. There is absolutely no indication about this having any impact of significance on the performance in the ecosystem at large. > There is no reason to make this change besides misguided ideology. There is zero benefit. Elimination of undefined behaviour by default (and so fewer crashes) and better security come to mind. Also, better compiler optimisations. This is explained in: https://openjdk.org/jeps/8305968 https://openjdk.org/jeps/8305968 The fact that you think this is of new benefit to you doesn't make this empty ideology. We have a couple of decades of vulnerability reports, customer support tickets, and challenges of introducing compiler optimisations that have sufficiently convinced us of the benefit. Not every Java user has to be convinced by every change to the JDK. In fact, we rarely make any JDK change that everyone is convinced we should do.

by pron 3y ago

jmaker 3y ago

As long as the deps haven’t all moved to the JDK without Unsafe, I think the ecosystem is tainted by such deps for the foreseeable future. In case you guys conducted an ecosystem survey, where are we at now? Lots are still running on JDK 1.8, some important deployments are on 1.6 or 1.7, even more are on JDK 11. The transition to JDK 17 has started only recently. How much more hesitant will this make projects to upgrade the JDK? There’s quite some tearing already due to 1.8, 11, and now 17, particularly with Pivotal EOL support for Spring 2.7 release train. I wish we could wait with it till the transition to 17 is complete.

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.
krzyk 3y ago
What is holding you back with upgrade to 17 or 21? Biggest pain was migrating 8 to 9, after that it is piece of cake.
- jmaker 3y ago
  The transitive hull of the deps
  - krzyk 3y ago
    Yeah, but you usually want to have up to date deps either way, at least for security purposes.
    - jmaker 3y ago
      Of course, a classical trade-off. That’s why I’m taking time to discuss that here. The cost incurred by upstream updates reshuffling the hull makes it for hard budget and timeline decisions and risk management. That’s why larger projects with many deps prefer stable upstream, both the runtime and the libs. There’s also compliance and certification that come into play in regulated industries. Lots of moving parts to keep track of. I need to know what the upstream vendors are up to so we can plan in advance. With JDK, a big trouble is the push to JDK 17+ now within the ecosystem. Sonar Cloud for example now wants JDK 17+ starting next Monday. But you can’t even build your JDK 11 bound projects with Gradle that runs on JDK 17. You could separate the build stage from the run stage, of course, but that’s not really enough in the end. Same story with Spring. With .NET by contrast, the ecosystem still supports the legacy .NET Framework target and you can still run your antiquated projects. Not the same with Java anymore though. It’s pulling the rug.
      - pron 3y ago
        Most Java projects written for JDK 1.2 still run fine, unchanged and without recompilation, on JDK 22, provided that they don't make use of libraries that bypass the spec and reach for internals (or unless they're using discontinued technologies like Applets, although those would still be easy to port). Java's backward compatibility only applies to the spec, not to internal implementation details. Before internals were encapsulated in JDK 16, too many libraries reached for internals, and these non-portable libraries made their client applications non-portable without their knowledge. Those libraries reached for internals to add functionality and to improve performance, but in the process knowingly sacrificed portability but didn't make that tradeoff apparent to consumers. Now that internals are encapsulated, upgrades are easier than they've ever been at any point in Java's history. Unfortunately, some large applications that depend on non-portable libraries — some of which were since abandoned — are stuck, but support for JDK 8 continues at lest until 2030.

pjmlp 3y ago

Even the JEP admits that there will be performance costs, which the team hopes won't matter for most use cases, hoping has never been a solution for anything.

pron 3y ago
You're defining "hope" as anything short of absolute certainty, so the same could be said about every significant new feature. Because we can never know with absolute certainty what impact it will have until it's seen some significant duration of use in the field, all we ever have is "hope" (guided by experience) that the benefit will have been worth the cost. Since our record is pretty good, I think, I don't see any more reason for concern in this case than in all others (not that that's ever stopped some people from expressing grave concern with pretty much every significant thing we do). In fact, why limit ourselves to technology? The same goes for deciding to make any change in anything. Every intentional change has only ever happened because someone had bet, without absolute certainty, that it will make things better. So you could say that "hope" is the only thing that has ever made anything better (or worse, I guess, if you're a glass-half-empty kinda guy).
- iscoelho 3y ago
  This is a false premise. We know today how performance will be affected by this. Java developers didn't just start using Unsafe for fun. They use Unsafe because they benchmarked, measured, and found a real performance gain. There is no reason to make this change besides misguided ideology. There is zero benefit.
  - pron 3y ago
    > We know today how performance will be affected by this. We know that a small subset of Unsafe-using code will have to continue using internals to keep performance and won't be able to use the supported APIs. There is absolutely no indication about this having any impact of significance on the performance in the ecosystem at large. > There is no reason to make this change besides misguided ideology. There is zero benefit. Elimination of undefined behaviour by default (and so fewer crashes) and better security come to mind. Also, better compiler optimisations. This is explained in: https://openjdk.org/jeps/8305968 https://openjdk.org/jeps/8305968 The fact that you think this is of new benefit to you doesn't make this empty ideology. We have a couple of decades of vulnerability reports, customer support tickets, and challenges of introducing compiler optimisations that have sufficiently convinced us of the benefit. Not every Java user has to be convinced by every change to the JDK. In fact, we rarely make any JDK change that everyone is convinced we should do.