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

[Ron Pressler]

> On 1 Sep 2023, at 21:21, Attila Kelemen <attila.kelemen85 at gmail.com> wrote:
> 
> I think this is missing the point of all the criticism. Most people don't mind the by default "strong integrity", but rather that the opt-out feature was designed to be the most painful imaginable. Actually, it is even worse than that, because it allows one way out: If you don't use the module system at all, then it is all easy. That is, it provides a strong incentive to stop using the module system. Something that was already a hard sell. It looks as if there was a hidden goal of killing the module system once and for all.

We’re not trying to sell or not sell anything. Different features may have different tradeoffs, and anyone is free to consider them and choose whether to use a feature or not. Every single Java program running on a version of the JDK after 8 is making extensive use of modules already — in fact, the entire JDK is built around them — so it’s pretty hard to kill. It’s started doing its job of protecting the integrity of the JDK. In fact, the value that modules’ integrity functionality has already delivered to the ecosystem so far has been enormous, but due to its “deep infrastructure” nature, not everyone realises that, and that’s perfectly fine. The work on integrity, however, is not complete but here we are working on it in our usual careful and gradual manner. 

Anyone who wants to enjoy that kind of integrity outside the JDK may author their own module. As the Future Work section explains, those who choose to do that may also enjoy reliable configuration benefits that won’t be available to those who don’t.

> 
> When you are arguing that the flag is simple, the often told reason is that people already pass a command line argument per module. Which is just completely false. Set aside that in non modular you can pass `-cp 'lib/*'` and in modular you are setting directories. Even if you explicitly list all the jars in "-cp", I have never seen anyone manually maintaining the "-cp" list. Rather the list is in this case automatically created by the build (or whatever other method). However, in case of `--enable-native-access`, you have to manually maintain this list.

-cp is a flag (even with ‘lib/*’), and the same work done to automate the classpath could be applied to this flag as well.

> 
> Adding insult to injury, you plan to first deliver this without the "future work" section (which is not even said, if it is planned to be delivered before the warning becomes an error). That is, in this case - while protecting the integrity of the JDK (which is not valuable without an actual application) - you are hurting the integrity of the application, because so far an application that worked can just randomly crash (I'm assuming the future where this becomes an error), which is not exactly the thing people would desire.

What we’re proposing to deliver first is a warning (BTW, the classpath currently, as it has ever, *does* cause a crash at runtime if the library configuration is incorrect). 

Among other things, it will allow us to judge the impact of a future change, and possibly adjust accordingly, including the relative prioritisation of the steps to follow (obviously including those in the Future Work section).

> 
> And you are saying that you want to give more power to the user. That would be fine, however you take away from others with seemingly no explanation. That is, why can't a user say, that: "In my application, I don't care about native calls". People must explicitly check all their dependencies, if they happen to use native calls, whether they want it or not, and can't just opt-out in a simple way.

See my point about automation above, and read the integrity JEP about the importance of the centralised audibility of the command line regardless of whether it’s constructed manually or automatically by some tool.

— Ron