> 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 w

> 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.