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

[Ron Pressler]

> On 4 Sep 2023, at 15:13, Attila Kelemen <attila.kelemen85 at gmail.com> wrote:
> 
>  I'm a bit confused, because I don't think your response is related to the quoted text, but I'll try my best.
> 
> I was referring to the fact that it is easier to opt-out for a non-modularized app from this JEP (I mean to avoid warning now / error later), than for a modularized app which creates a perverse incentive to avoid creating modularized apps.

But the incentive for using modules in the first place is to have individual control over modules (compartmentalisation) as opposed to the entire application as a big ball of mud. If you opt in for individual control over modules and compartmentalisation by using the module path, why would the assumption be that you’re looking for an easy opt-out from the very effect that modules are intended to provide?

> As for "fail fast": That would be great, but that is another of my issue that - in its current state of the JEP - it is not possible, because that would require the future work section, which I consider to be too important to leave it for the undefined future (so important that I think without it this JEP carries some danger with it). And the phrasing "we may explore ways" in the JEP doesn't sound like a commitment either. This is because without fail fast behaviour what is expected from users? The assumption of the JEP that a user is unsure about the native usage within his/her app (which for example is true for me, because I had my share of nasty surprises because of it).

The assumption in the JEP, which is supported by past experience, is that at least one of the warning or the flag are not deal breakers, and this will allow us to prioritise our future work, while warning people of a future change as soon as possible.

BTW, we try not to commit to any feature or timeline ever. I’ve made that mistake and regretted it. While we do shift priorities around, and we’ve certainly disappointed those who’ve eagerly waited some particular feature or another many times, I hope people are generally happy with what we’ve delivered and the pace at which we’ve delivered it (although there are those asking us to move faster, while others ask us to move slower). From those who are generally happy I’ll only ask for the benefit of the doubt that we do consider all aspects we need to consider and balance them more-or-less well; generally speaking, of course.

So yes, we have considered the points you raised:

> However, this person now has to list all the modules using native using modules. How is he/she supposed to do that? Run the app, if it fails (for now prints warnings), then add the command line option, and try again until the problem stops? But even after doing so, the user can never be fully confident that the app will never have a surprise native call based on some rare to trigger condition (and rare trigger did happen to me in practice).

Yes, but since very few application use more than one or two JNI libraries, few applications are currently modularised, and we’ve seen quite a few applications shipped with warnings over the past few years, I think other work is more urgent. Because it’s possible that some future anticipated feature would require JNI to be restricted as a prerequisite, it may be best to start warning people about an upcoming change sooner rather than later. Again, this is all assuming that the combination of a warning and a flag won’t have a catastrophic effect, and experience suggest it doesn’t. The risk of doing what you propose is that either we’ll need to postpone work we know to be more important to work on this now, or to postpone the warning, which will postpone the restriction, which will postpone some anticipated features that may require it, which will disappoint many more people.

Obviously, we can’t expect commenters to be able to take all those considerations into account, which is why we only ask if anyone can spot a major flaw. All I can say is that the risk that authors of modular applications may need to do more work (though it’s not likely that it’s significantly more, or that it’s even unwelcome) is one of the aspects that we consider. 

— Ron