<div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>As mentioned, a fix to issues like these would be to either</div><div>- Make the JNI flag a module setting; or</div><div>- Make JNI usage opt-out instead of opt-in; or</div><div>- Don't restrict JNI usage at all.</div><div><br></div><div>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.</div><div><br></div><div>Constantin<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 28. Aug. 2023 um 23:36 Uhr schrieb Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>>:<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 21:58, Spam mail <<a href="mailto:4evnyuij@gmail.com" target="_blank">4evnyuij@gmail.com</a>> wrote:<br>
> <br>
> You don’t need to add a flag to the startup args to use a library..?<br>
> <br>
> The classpath manifest entry exists, and shading is still a very prominent thing (although not the best practise). A medium-sized application with ~7 libraries can be launched with java -jar app.jar just fine, if you configure your build correctly.<br>
<br>
I said a flag or a manifest attribute or something even more complicated (by which I referred to shading). Therefore, requiring another flag or a manifest attribute won't make building or launching that 7-library program significantly harder, however you choose to build it or launch it.<br>
<br>
— Ron</blockquote></div>