<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
The integrity of the platform is very important to us for the multiple reasons that I mentioned before, one of which is precisely because we’d like code that runs on Java N to also run, unchanged, on Java N+5. One of the main causes for that not happening in the past has been a lack, not excess, of integrity. We want to get to a place where most Java programs would, by default, be assured that they’re portable and enjoy all the safety guarantees that Java can offer.<br>
<br>
Yes, unfortunately that means introducing some inconvenience. The inconvenience is not the goal, it’s just a necessity, and we’re sorry we have to impose it. We’re doing our best to keep it as minimal as we can.<br>
<br></blockquote><div><br></div><div>I think this is missing the point of all the criticism. Most people don't mind the by default "strong integrity", but rather that the opt-out feature was designed to be the most painful imaginable. Actually, it is even worse than that, because it allows one way out: If you don't use the module system at all, then it is all easy. That is, it provides a strong incentive to stop using the module system. Something that was already a hard sell. It looks as if there was a hidden goal of killing the module system once and for all.</div><div><br></div><div>When you are arguing that the flag is simple, the often told reason is that people already pass a command line argument per module. Which is just completely false. Set aside that in non modular you can pass `-cp 'lib/*'` and in modular you are setting directories. Even if you explicitly list all the jars in "-cp", I have never seen anyone manually maintaining the "-cp" list. Rather the list is in this case automatically created by the build (or whatever other method). However, in case of `--enable-native-access`, you have to manually maintain this list.</div><div><br></div><div>Adding insult to injury, you plan to first deliver this without the "future work" section (which is not even said, if it is planned to be delivered before the warning becomes an error). That is, in this case - while protecting the integrity of the JDK (which is not valuable without an actual application) - you are hurting the integrity of the application, because so far an application that worked can just randomly crash (I'm assuming the future where this becomes an error), which is not exactly the thing people would desire.</div><div><br></div><div>And you are saying that you want to give more power to the user. That would be fine, however you take away from others with seemingly no explanation. That is, why can't a user say, that: "In my application, I don't care about native calls". People must explicitly check all their dependencies, if they happen to use native calls, whether they want it or not, and can't just opt-out in a simple way.</div></div></div>