<div dir="ltr"><div dir="ltr"><div dir="ltr">You keep emphasizing "end user", trying to prove that you are giving more power to the end user.<br></div><div dir="ltr">Is this real? It doesn't look like it. You are just forcing more obligations on them.<br></div><div dir="ltr"><br></div><div dir="ltr">Is --enable-native-access really giving the end user more control? Mostly not.<br></div><div dir="ltr">In most cases, the actual control is always in the hands of the developer, <br></div><div dir="ltr">--enable-native-access just forces the end user to sign their name on the agreement, even if they don't want to read it.</div><div dir="ltr">If they don't sign this agreement, the program will crash at random moments.<br></div><div dir="ltr">Does this forced-signed agreement have any practical significance other than helping developers shirk their responsibilities?</div><div dir="ltr">If the end user really wants to audit all dependencies, this can be done even without the --enable-native-access option.<br></div><div dir="ltr">Declaring these in module-info can also aid in review.<br></div><div dir="ltr"><br></div><div dir="ltr">Can --enable-native-access make the behavior of the program more transparent? I'm not sure, but I guess not.<br></div><div dir="ltr">Library authors can hide implementation details by simply bundling dependencies into their own modules using tools like shadow jar.<br></div><div dir="ltr">This is a great idea and has no downsides other than having a hundred duplicate dependencies in different packages in my program.<br></div><div dir="ltr">That's it, --enable-native-access has no advantage in making a program's behavior transparent over exposing its behavior in module-info, </div><div dir="ltr">and may instead force library authors to hide implementation details in other ways.<br></div><div dir="ltr"><br></div><div dir="ltr">Can --enable-native-access prompt the end user that the program may break integrity?<br></div><div dir="ltr">I think this is the only reason I can agree with. </div><div dir="ltr">But it's no better than the `-Dforeign.restricted=permit`, if for that reason alone.<br></div><div dir="ltr"><br></div><div dir="ltr">As stated above, I completely disagree with the reasons you gave. I think it will cause more problems than it solves.<br></div><div dir="ltr"><br></div><div dir="ltr">First, it will definitely cause a lot of program crashes due to not adding JVM options correctly.<br></div><div dir="ltr">Some may be due to lack of familiarity with the library, some may be due to forgetting, </div><div dir="ltr">and some may be due to the startup script not being updated correctly along with the program.<br></div><div dir="ltr">In any case, we cannot avoid it. It may cause more damage in reality than the breach of integrity it avoids.<br></div><div dir="ltr"><br></div><div dir="ltr">I've spoken many times about the complexity that having to use JVM options brings to small programs, so I won't repeat it here.<br></div><div dir="ltr">What I want to point out here is that there is currently no standardized way to pass JVM options between dependencies in the Java ecosystem.</div><div dir="ltr">The current mainstream way is through documentation. However, if you do decide to impose --enable-native-access restrictions on FFI, </div><div dir="ltr">then this will push the community to pass this information in the POM or Gradle Module Metadata and have the JVM options automatically generated by the build tool.<br></div><div dir="ltr">This may seem fine, but the community will care more about user convenience and less about integrity and other things you care about.<br></div><div dir="ltr">If you let the community do it, they might allow libraries to declare that they require --add-opens/--add-exports in a similar way.<br></div><div dir="ltr">Library authors will no longer be so careful to avoid breaking integrity, which would cause irreparable damage to integrity.<br></div><div dir="ltr"><br></div><div dir="ltr">I want to know if you collected enough user opinions before making such a major decision?<br></div><div dir="ltr">Not only the opinions of senior programmers at individual top companies, but also the opinions of programmers in small companies are also important.<br></div><div dir="ltr">I went to ask many Java programmers for their opinion on this decision.<br></div><div dir="ltr">Most of them feel that this is a stupid decision, and the rest feel that this will be their reason to abandon Java.<br></div><div dir="ltr">Although this is just a local survey, I think it is representative to a certain extent.<br></div><div dir="ltr">I hope you will think twice before you act.</div><div dir="ltr"><br></div><div dir="ltr">Glavo</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 29, 2023 at 11:57 PM Glavo <<a href="mailto:zjx001202@gmail.com">zjx001202@gmail.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"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">The means to be able to break the abstraction of the dependency hierarchy are unconventional.<br></div><div dir="ltr">I don't think all the reasons you have given so far are enough to justify using this unconventional means.<br></div><div dir="ltr">I hope you will use these means more carefully, abuse of them will weaken their warning effect.<br></div><div dir="ltr"><br></div><div dir="ltr">Glavo</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>
</blockquote></div>