[External] : Re: JEP draft: Prepare to Restrict The Use of JNI

[Ron Pressler]

> On 29 Aug 2023, at 11:53, Holo The Sage Wolf <holo3146 at gmail.com> wrote:
> 
> > Users have always had the right to know what they're doing if they want to.
> 
> How, today, can a user know if they use JNI? 
> 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.
> 
> 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.
> 
> But i don't think there is a way to make sure the users are aware of JNI usage without at least 1 flag

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.

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.

— Ron