3 ms·

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 becaus

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.
- iscoelho 3y ago
  > There is absolutely no indication about this having any impact of significance on the performance in the ecosystem at large. You seem to be really averse to evidence. In my opinion, the JEP should have benchmarks. It does not have any. I would say that raises concern for lack of credibility and shows dishonesty. > 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 There is nothing stopping a compiler from omitting conflicting optimizations in functions using "unsafe". Undefined behavior due to optimizations is also already commonly understood in C/C++. If you don't like codebases using unsafe, don't use them! > In fact, we rarely make any JDK change that everyone is convinced we should do. That's a very round-about way of saying "we only do what we want and who cares about the users". Funny.
  - pron 3y ago
    > You seem to be really averse to evidence. You have evidence that a significant portion of the ecosystem will suffer some performance degradation? If so, it would be immensely helpful if you could share it on the mailing list. We take each and every report seriously. > In my opinion, the JEP should have benchmarks. The Panama project has been publishing and discussing benchmarks for years. Here's one example: https://mail.openjdk.org/pipermail/panama-dev/2020-November/011342.html https://mail.openjdk.org/pipermail/panama-dev/2020-November/... I don't understand, however, what kind of benchmark could show that most libraries can migrate from Unsafe to FFM without adversely affecting most of their client applications. I'm sure you can find some discussions about performance on panama-dev, where JDK developers have been working with library authors and other Java users on the project for the past years. > There is nothing stopping a compiler from omitting conflicting optimizations in functions using "unsafe". Undefined behavior due to optimizations is also already commonly understood in C/C++. Yeah, the world is moving away from undefined behaviour; Java is certainly not going to start moving toward it. Avoiding unspecified behaviour has sort of been one of Java's main selling points from day one. Because we've been delivering significant performance improvements while improving safety at the same time for years (JDK 21 improves the performance of a lot of applications by a significant amount compared to JDK 8, all without changing a line of code), I can't see a reason why we should change our strategy now. We don't need to let undefined behaviour more easily in to give our users the performance they want. So while we allow undefined behaviour with a flag, allowing it by default would mean it could be everywhere, and most of our users prefer safety to be the default, also in line with the global trend. > If you don't like codebases using unsafe, don't use them! The problem is that a Java application has no easy way of knowing whether some transitive dependency may be using Unsafe. The integrity JEP goes into that. > That's a very round-about way of saying "we only do what we want and who cares about the users". Funny. It means we have 10M opinionated users, we work very hard to make sure we satisfy most of them with most of what we do (after all, our job depends on Java's continued thriving, which depends on our users' happiness), but even if 1% is unhappy with something we do, and 1% of those express their opinion on social media, that's 1000 angry people saying they're not being listened to. The fact is that different programmers want different things, often those things are contradictory, and it's quite rare to find something that millions of programmers agree on. I don't know if it's funny or not, but part of doing this job is knowing that you work all day, every day, to make most of your users happy, and no matter what you do or don't do, there will be people yelling at you on social media, because programmers just can't all agree on pretty much anything. But I'm not complaining. The overall satisfaction with our recent features and releases has been palpable.

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.

iscoelho 3y ago
> There is absolutely no indication about this having any impact of significance on the performance in the ecosystem at large. You seem to be really averse to evidence. In my opinion, the JEP should have benchmarks. It does not have any. I would say that raises concern for lack of credibility and shows dishonesty. > 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 There is nothing stopping a compiler from omitting conflicting optimizations in functions using "unsafe". Undefined behavior due to optimizations is also already commonly understood in C/C++. If you don't like codebases using unsafe, don't use them! > In fact, we rarely make any JDK change that everyone is convinced we should do. That's a very round-about way of saying "we only do what we want and who cares about the users". Funny.
- pron 3y ago
  > You seem to be really averse to evidence. You have evidence that a significant portion of the ecosystem will suffer some performance degradation? If so, it would be immensely helpful if you could share it on the mailing list. We take each and every report seriously. > In my opinion, the JEP should have benchmarks. The Panama project has been publishing and discussing benchmarks for years. Here's one example: https://mail.openjdk.org/pipermail/panama-dev/2020-November/011342.html https://mail.openjdk.org/pipermail/panama-dev/2020-November/... I don't understand, however, what kind of benchmark could show that most libraries can migrate from Unsafe to FFM without adversely affecting most of their client applications. I'm sure you can find some discussions about performance on panama-dev, where JDK developers have been working with library authors and other Java users on the project for the past years. > There is nothing stopping a compiler from omitting conflicting optimizations in functions using "unsafe". Undefined behavior due to optimizations is also already commonly understood in C/C++. Yeah, the world is moving away from undefined behaviour; Java is certainly not going to start moving toward it. Avoiding unspecified behaviour has sort of been one of Java's main selling points from day one. Because we've been delivering significant performance improvements while improving safety at the same time for years (JDK 21 improves the performance of a lot of applications by a significant amount compared to JDK 8, all without changing a line of code), I can't see a reason why we should change our strategy now. We don't need to let undefined behaviour more easily in to give our users the performance they want. So while we allow undefined behaviour with a flag, allowing it by default would mean it could be everywhere, and most of our users prefer safety to be the default, also in line with the global trend. > If you don't like codebases using unsafe, don't use them! The problem is that a Java application has no easy way of knowing whether some transitive dependency may be using Unsafe. The integrity JEP goes into that. > That's a very round-about way of saying "we only do what we want and who cares about the users". Funny. It means we have 10M opinionated users, we work very hard to make sure we satisfy most of them with most of what we do (after all, our job depends on Java's continued thriving, which depends on our users' happiness), but even if 1% is unhappy with something we do, and 1% of those express their opinion on social media, that's 1000 angry people saying they're not being listened to. The fact is that different programmers want different things, often those things are contradictory, and it's quite rare to find something that millions of programmers agree on. I don't know if it's funny or not, but part of doing this job is knowing that you work all day, every day, to make most of your users happy, and no matter what you do or don't do, there will be people yelling at you on social media, because programmers just can't all agree on pretty much anything. But I'm not complaining. The overall satisfaction with our recent features and releases has been palpable.