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

[Ron Pressler]

> On 1 Sep 2023, at 22:16, Attila Kelemen <attila.kelemen85 at gmail.com> wrote:
> 
> Yet, this JEP just motivates people away from modules.

I can’t follow this logic. You use modules if you want a finer grained control over integrity, not coarser grained, because you want to know what each of them can do *individually* so you can gain better maintainability, better security, and maybe someday better performance.  

However, as I’ve said before, a way to inherit native access permissions is something we could consider if configuring native access for modules ends up being a problem in practice, something that the proposed warning will help us determine. How many libraries requiring native access an application uses is also a factor. Who knows? Maybe we would want to offer a way to allow native access to all modules. But we don’t design solutions to problems that may not exist. To know more, we’ve presented a JEP that emits a warning and offers a simple mechanism to disable it, which hopefully will let us learn what if any changes to that simple mechanism are required.

> Also, I'm not sure how you would automate the application of `--enable-native-access` arguments? Because the classpath you can easily do so, since build tools offer you a simple way to enumerate your dependencies, but what way do I have to enumerate the module names requiring native access during the build automatically?

How do the build tools enumerate all those transitive dependencies?

— Ron