<div dir="auto">The reason I want to add this to the module-info is not to avoid flags. I don't mind flags at all.<div dir="auto"><br></div><div dir="auto">What brothers me is how unorganized it is, and how it only bits you on load time. If we put it in the module-info, we can (1) issue the warning (and later the error) at compile time and (2) you can follow hereditarily what uses JNI.</div><div dir="auto"><br></div><div dir="auto">This is very helpful for people who writes wrapper libraries to low level libraries that uses JNI.</div><div dir="auto"><br></div><div dir="auto">So *even if* the end decision is to require a flag for every module (which I don't think is necessary), adding this information to the module-info is still extremely important in my opinion.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 29, 2023, 14:14 Ron Pressler <<a href="mailto:ron.pressler@oracle.com" target="_blank" rel="noreferrer">ron.pressler@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On 29 Aug 2023, at 11:53, Holo The Sage Wolf <<a href="mailto:holo3146@gmail.com" rel="noreferrer noreferrer" target="_blank">holo3146@gmail.com</a>> wrote:<br>
> <br>
> > Users have always had the right to know what they're doing if they want to.<br>
> <br>
> How, today, can a user know if they use JNI? <br>
> The point is to make it impossible for a user to be unaware of any JNI uses which *at the very minimum* requires you to declare it in the command line.<br>
> <br>
> Although *I absolutely* agree that it should also be added to the module-info, so instead of having to specify every module that uses JNI in the flag, you could only specify the Main module, and in there it's module-info will open the JNI usage for every module.<br>
> <br>
> But i don't think there is a way to make sure the users are aware of JNI usage without at least 1 flag<br>
<br>
Right, except you can already do that, only in a more appropriate place than the main module. The model is that modules declare what they require and what they provide. They don’t grant permissions to other modules or control other modules in other ways. That is all done in the centralised place where the application is configured, which is not the main module but the application launcher, which you set up either with jlink, a manually written startup script, or with @files.<br>
<br>
I get a sense that people don’t want command line flags but some other configuration file, but any Java command line option can already be put in some more persistent and shareable way either with jlink or with @files. Java applications now finally have a way to be fully self-contained and self-configuring, something that was much harder than in the days of the JRE. Obviously no one is expecting that the actual end user of the application type flags that mean nothing to them. In fact, these days the end user doesn’t even need to install a Java runtime nor even know or care that the program is written in Java. All command line options are internal to the application.<br>
<br>
— Ron</blockquote></div>