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

[Ron Pressler]

> On 2 Sep 2023, at 12:18, Attila Kelemen <attila.kelemen85 at gmail.com> wrote:
> 
> The logic is simple: There are a lot of people who don't care if their app uses native calls, and don't like this JEP. These people want the simplest way to turn off the potential warning / error. The simplest way to turn it off is to not modularize your application (because then you can turn it off with a single parameter or even manifest entry). Therefore it just follows that these people are motivated to not modularize their application. That is, this JEP creates a perverse incentive.

1. To me this sounds like “a lot of people don’t like flying, so if planes weren’t designed to easily cruise on water, those people will be disincentivised to travel by plane.” Modules exist (among other things) to offer finer-grained control over integrity (though not as fine-grained as that offered by SecurityManager because we must balance granularity and simplicity).

2. You seem to assume that there is some big difference between allowing all modules and allowing them one by one, but that depends on the number of libraries that use JNI in an application. I think that number is not frequently higher than one (and very rarely higher than three), but this JEP offers a way to find out. Why should we spend time *right now* on solving something that may end up not to be a problem in practice if we have actual problems to work on?

> 
> I'm worried that this might cause long lasting damage, because it instills an extra irrational fear into people.

We’re worried about things like that, too, as well as the long lasting damage of lack of integrity by default, so we try to balance everything, and offer the most careful change that would allow us to validate the approach before going further.

You need to understand that Java users demand contradictory things. For virtually any X that people demand, others demand the opposite. It’s not some new insight that we have to take into account, but a certainty that comes with the job. Obviously for pretty much any JEP we do there would be a sizeable group of developers that dislike it or, at the very least think we’re wasting our time on something unnecessary. If there weren’t they wouldn’t be developers, because developers are certain about contradictory things.

There is simply no way to offer both integrity by default and lack of integrity by default. No matter what, we must inconvenience SOMEONE, and that’s unfortunate. But years of work have gone into adding features that would make integrity by default viable while only causing a small amount of inconvenience for those who want to opt out. 

And we’re not even content with that, which is why we’re so careful and want to validate the approach before restricting anything. I hope you can see the irony in someone saying, “I fear that even validating the approach may cause damage, so don’t, and just trust me,” but I assure you that if it turns out that the inconvenience cause will be as immense as you fear, we’ll make the necessary changes. I hope that you take is at a given that no one on this planet is as committed to making the experience of using Java better (integrated over the entire ecosystem) than the stewards of the platform. Thinking how to make it better is what we do all day, every day. Everything we do helps some and hurts some (if only because it means we’re not doing something else), and we wouldn’t propose anything if we thought that it helps much more than it hurts.

> 
> Every library records their own direct dependency, and the build tool can just traverse this graph

There you go. I think you’ve answered your own question.

— Ron