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

[Attila Kelemen]

>
>
> The integrity of the platform is very important to us for the multiple
> reasons that I mentioned before, one of which is precisely because we’d
> like code that runs on Java N to also run, unchanged, on Java N+5. One of
> the main causes for that not happening in the past has been a lack, not
> excess, of integrity. We want to get to a place where most Java programs
> would, by default, be assured that they’re portable and enjoy all the
> safety guarantees that Java can offer.
>
> Yes, unfortunately that means introducing some inconvenience. The
> inconvenience is not the goal, it’s just a necessity, and we’re sorry we
> have to impose it. We’re doing our best to keep it as minimal as we can.
>
>
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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230901/99fc8214/attachment-0001.htm>