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

[Attila Kelemen]

>
> > 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).
>

I don't think I can follow your comparison. If a plane could travel on
water, then when used to travel on water, it is indistinguishable from a
ship. So, changing a plane like that wouldn't change anything for anyone.
While in my example, many people will take the easy way out. Because they
will consider two scenarios:

1. Using modules: +Maybe some integrity benefit, -I'm punished by this JEP.
2. Not using modules: -Lose module benefits, +I can easily opt-out from
this JEP.

Now someone who doesn't care about the integrity benefit of this JEP (the
vast majority, which honestly makes me sad, because I personally like
having the option of having a strong control over native access) is
unlikely to care about the integrity benefits of the modules (it is a lack
of care for integrity in both case). Thus, they will very likely pick
option 2, while without this JEP, they would have been a lot easier to
convince to go with modules. That is, the presence of this JEP will make
less people use modules than, if this JEP was not implemented. Just to
clarify again: I'm definitely not against integrity by default (I'm all for
that). What I'm arguing for is an easier way to opt-out
for modularized applications.


> 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?
>

Most likely in practice that is true. However, when I will try convincing
people to move to modularized applications, people will simply not give it
a chance (I have a lot of experience in trying to push people into more
structured directions, and it is tough, and I believe you would agree with
this). It would be far easier, if I could just ask people to modularize
their application, and they don't get a bonus excuse. Then once that is
established, I might be able to convince them with tighter native access
control. In other words: Making people jump over two lower bars is a lot
easier than making them jump over the sum of the two in one go.


> 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.
>

Again, that is not what most people are asking for. The request is an
easier way to opt-out. The integrity by default option I'm fine with (in
fact, I do prefer so).

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.
>

If I didn't think your goal is to do what is the best for the platform,
then I wouldn't write anything (or maybe I would be writing emails to the
contrary to trick you :)). While of course it is certainly possible that
I'm worried for nothing, and there is no reason to be more careful, there
is at least one fact to consider for sure: This JEP received almost
exclusively negative reception. While that is no proof (especially since
people in favor are less likely to write) it should be taken into
consideration. Especially since even though many features get negative
feedback, it is rare (at least I don't see it often), that it is so
overwhelmingly negative.


> >
> > 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.
>

I don't understand. Where will it be recorded for the build tool to pick it
up just like the dependencies automatically? As far as I can see it would
require the "future work" section, but that mentions this with a "we may
explore ways" which is far from being a commitment. So, as far as this JEP
goes, I don't see there can be such automation done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230902/b88ff936/attachment-0001.htm>