<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Are you saying that Java developers are able to learn the difference between, say, VarHandle and Unsafe but not between --enable-native-access and --add-opens? Yes, there are some differences. Unsafe is in a suspiciously-named package and VarHandle is not while the two flags are just flags (and perhaps we should have named add-opens `unsafe.add-opens` but that ship has sailed). But I think that the main difference is that --enable-native-access is simply new, which means that Java developers will have to learn what it means, just as they do with any new feature.<br></blockquote><div><br></div><div>Why does --add-opens have sufficient warning effect? Because this option brings negative feedback.<br></div><div>It creates pain for authors of low-level libraries, authors of high-level libraries that depend on low-level libraries, and end users, forcing them to move away from --add-opens.<br></div><div>I agree with this approach, this kind of pain that cannot be borne by anyone alone is indeed a means of forcing users to leave.<br></div><div><br></div><div>However, --enable-native-access is abusing negative feedback.<br></div><div>FFI is a legitimate requirement, and many applications cannot avoid using them.<br></div><div>You try to inflict inescapable pain on everyone, and the result may be:<br></div><div><br></div><div><ol><li>Pushing People Out of the Java Ecosystem;<br></li><li>Get people used to pain.<br></li></ol><div>When people get used to the pain it causes, --add-opens can't give enough negative feedback that it will do irreparable damage to integrity.<br></div></div><div><br></div><div>Glavo</div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 29, 2023 at 5:15 PM Ron Pressler <<a href="mailto:ron.pressler@oracle.com" target="_blank">ron.pressler@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 29 Aug 2023, at 01:49, Glavo <<a href="mailto:zjx001202@gmail.com" target="_blank">zjx001202@gmail.com</a>> wrote:<br>
> <br>
> Integrity-breaking options such as --add-opens warn users that they are working in an unusual way.<br>
> This is a strong warning that users should use a safe alternative and should try not to use this option.<br>
> <br>
> But --enable-native-access is different.<br>
> In practice, FFI is very commonly used and cannot be abandoned for a foreseeable long time.<br>
> --enable-native-access will be the only way to enable FFI, which means that a lot of normal applications<br>
> will have to use integrity-breaking options for a long time.<br>
> This is a red flag, which means that users will be less vigilant about breaking integrity.<br>
<br>
Are you saying that Java developers are able to learn the difference between, say, VarHandle and Unsafe but not between --enable-native-access and --add-opens? Yes, there are some differences. Unsafe is in a suspiciously-named package and VarHandle is not while the two flags are just flags (and perhaps we should have named add-opens `unsafe.add-opens` but that ship has sailed). But I think that the main difference is that --enable-native-access is simply new, which means that Java developers will have to learn what it means, just as they do with any new feature.<br>
<br>
— Ron</blockquote></div>