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

[Glavo]

I think I've calmed down now. Now let me calmly sort out the issues in our
dispute:

1. You classify the ability to break integrity as a "superpower", and use
the problems that some superpowers
bring to prove that all superpowers should be limited. I don't agree with
this.
I think that although JNI (and I/O) are also superpowers and can indeed be
used to cause trouble in theory,
they are essentially different from the superpowers that actually cause
trouble:

    1. Users have historically preferred pure Java implementations, using
JNI almost only when necessary and no replacement.
        Therefore, even if JNI is marked as "unsafe", it is difficult for
users to return to the safe field, so in essence,
        this will not make more people to enjoy integrity.
    2. JNI has been widely used, but it has not actually hindered JDK
development by being abused to break integrity.

I can understand the point of JPMS, but for the reasons above, the benefits
of restricting JNI are far less than the benefits of JPMS.
So I don't think "we have tasted the benefits of restricting some
superpowers in the past" is a sufficient reason to continue to restrict
other superpowers,
we need more practical reasons.

2. You're emphasizing that there is an "end user" independent of the
developer, not even the author of the main module, which confuses me.
In my experience, the developer of the main module and the "end user" of
the packaged program are often the same person/group of people.
I don't understand why it is necessary to distinguish between the two
identities.
If you think it is necessary to distinguish between the two identities,
then I think that no matter which identity I am, I find your proposal
unappealing and causing trouble:

    * When I'm a developer, I consider it my obligation to provide a
program with integrity that won't crash.
      I take it for granted, since I'm the one fixing the bugs. Whether
it's a JVM crash or a code logic error, it's all my responsibility.
      I don't know what good this proposal would do for me.
    * When I am the "end user". Ummm, I don't even know what my role is on
the team. Leader? Reviewer? Build script writer? O&M Personnel?
      Well, whatever I am, I'm not happy with the proposal. Why do I get
this list of modules from a developer and then ask me to write it again?
      Obviously, I don't have permission to modify this list. If I modify
it, the program will crash at random moments.
      If I want to review it, then it’s fine if the developer writes it and
I am responsible for reviewing it. Why should I write it again?
      I think this will just lead to more crashes due to incorrect
configuration.

3. Why should end users care about low-level libraries?
You said this:

And if you think that’s the worst of it, well, get a load of this. Some
> serialization libraries, say, those that can deserialise JSON, need to set
> private (perhaps even final) fields and instantiate objects without calling
> a constructor. This, of course, requires breaking access control, the
> invariant that supports all others. So they use a low-level library with
> superpowers that break access control. So far, everyone has the best
> intentions. However, the JSON library deals with input that arrives to the
> application from the outside world, and that input determines which fields
> it sets and which objects it instantiates without a constructor. A
> vulnerability in that innocent library can direct its action toward
> critical JDK classes, and because the operation is done by using a
> super-powered low-level library, there are no longer any access checks in
> its way. So, everyone here is well meaning — the application and both
> libraries; the vulnerability is not in the super-powered library. But now a
> vulnerability in one library can have a catastrophic effect because there
> is some transitive dependency with superpowers.
>

You are right, the error may occur due to misuse of low-level libraries by
high-level libraries. So shouldn't we care more about high-level libraries?
Low-level libraries may not have any bugs, and focusing on it may be a
waste of time. So why should end users care about these low-level libraries?

4. I'm surprised and puzzled by your negative attitude towards feedback.


> Now I’d like to say something general about feedback. Java users demand
> things that are contradictory; it is simply impossible to satisfy them all.
> Our job is to take into account those contradictory demands and find a path
> that provides the most value for the least cost when integrated over the
> ecosystem as a whole. Obviously, no matter what we do or don’t do, some
> portion of users will be negatively affected and they’ll have a negative
> opinion of some change or lack thereof. Such opinions are inescapable, but
> also unhelpful. Obviously some people weren’t happy when applications broke
> when migrating from 8 to 9 because Java didn’t have integrity by default,
> while others aren’t happy that integrity by default requires them to add a
> flag when they want to selectively give up on integrity. Similarly, I hope
> it goes without saying that the time and money that went into designing and
> developing the features that allow us to achieve integrity by default in
> the hopefully no-so-distant-future, by people with cumulative centuries of
> work on OpenJDK behind them, represents a significant amount of thinking.
>

Yes, there are always supporters and opponents of a proposal, so the
objections don’t matter?
Objection implies an opinion: The status quo is better than your proposal.
Therefore, they don't necessarily have to provide their own solutions.

I did a survey, and while it wasn't extensive, it had a fairly high
percentage of negative feedback. This shows that there are indeed many
people who are dissatisfied with this,
so I hope you have a stronger case for this proposal. But up to now, I
think the reasons you gave are very insufficient. As I mentioned earlier:

So I don't think "we have tasted the benefits of restricting some
> superpowers in the past" is a sufficient reason to continue to restrict
> other superpowers, we need more practical reasons.
>

Also, I've given my proposal many times before (based on module-info), but
you are just emphasizing that even the "main module author" is not the "end
user".
I don't think this is a reliable reason.

Glavo



On Sat, Sep 2, 2023 at 5:49 PM Ron Pressler <ron.pressler at oracle.com> wrote:

>
>
> > On 2 Sep 2023, at 08:06, Simon Nash <simon at cjnash.com> wrote:
> >
> > As I pointed out in my earlier message, although the end user of the
> application does not need to specify the flag, they do see the scary
> warning written to stderr when the flag is not present. This will happen
> when an a older version of an application that uses JNI is run on a newer
> version of the JDK.
>
> They do not need to see the flag even if the flag is there. We’re talking
> about flags passed to the JVM, not to the application launcher. Also, all
> JVM flags can, as always, be put in configuration @files; there’s no need
> to actually type them on the command line.
>
> >
> > This will scare these end users and is likely to reinforce the incorrect
> perception that Java is unsafe and Java-based applications should be
> avoided.
>
> Java has been issuing warnings like this multiple times over the past five
> years. Another one was just added in JDK 21. This is the standard practice
> in Java to prepare for future changes.
>
> — Ron
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230902/8bb65b71/attachment.htm>