<div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>There is a huge difference between --add-opens and --enable-native-access here. While the sole purpose of --add-opens is to break encapsulation and open implementation details, dependence on which is a major factor causing the friction of migration from 8 to 9, the purpose of JNI is not to break anything, but to simply enable native accesses from Java. While encapsulation breakage is possible in JNI, equating it as its sole purpose seems illogical. As a result, forcing the users to treat it similarly as --add-opens and friends seems not to be reasonable to me.</div><div><br></div><div>Thanks,</div><div>Quan Anh</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 29 Aug 2023 at 06:27, Ron Pressler <<a href="mailto:ron.pressler@oracle.com">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 28 Aug 2023, at 23:04, Constantin Christoph <<a href="mailto:4evnyuij@gmail.com" target="_blank">4evnyuij@gmail.com</a>> wrote:<br>
> <br>
> But now, what if instead of making an application using a JNI-using library, I am making a library using JNI myself? I have absolutely zero control over whether JNI will work when my library is used, it is up to the user of the library to figure out that a flag needs to be added to the startup arguments. Now imagine that a few more libraries are in between my library (using JNI), and the end user. The JNI-heavy feature is now behind several layers of abstraction, and may not even get called until a very niche use case happens, and if the startup argument isn't present at that time, the program crashes. A notice from me regarding my library's usage of JNI *will* be overlooked at some point, and you can't always feasibly catch errors like this in testing.<br>
<br>
See the Future Work section. Modules offer strong encapsulation (integrity) and reliable configuration. Now that we have a model for both, we can offer them at different times.<br>
<br>
> <br>
> This is just another example of what will inevitably happen when these changes are in full effect, and the tradeoff is just not worth the hours of lost developer time that will undoubtedly need to be sacrificed to fix issues like these.<br>
> <br>
> As mentioned, a fix to issues like these would be to either<br>
> - Make the JNI flag a module setting; or<br>
> - Make JNI usage opt-out instead of opt-in; or<br>
> - Don't restrict JNI usage at all.<br>
> <br>
> This is my final stance on the subject manner: The changes should not be made in their current state. You just cannot change such an old interface that drastically, a lot of libraries will break, and a lot of developers will be disappointed.<br>
<br>
You say that a tradeoff is not worth it but only mention one of its arms. Still, you can disagree about the tradeoff, but requiring the addition of a couple more tokens to a command line that has dozens more is not drastic. Yes, it is certainly true that we’re changing something and, sadly, providing integrity by default requires us to do just that in multiple areas. What has changed drastically is the pace in which the JDK is changing (*much* faster now than ever before in the last 20 years) and the way it is written (more in Java, less in native, which makes the platform more sensitive to Java-level integrity guarantees). I hope and believe that most Java users think that’s a very, very good thing. But to allow that, we have to make some (hopefully not as drastic) changes in the way a Java application is composed and deployed, because we saw the pain caused by lack of integrity in the 8 -> 9+ migration, and we don’t want that risk to continue forever. So yes, there will be some work required now, we’ll be in a much better place on the other side.<br>
<br>
— Ron<br>
<br>
</blockquote></div></div>