JEP draft: Prepare to Restrict The Use of JNI

[Ryan Schmitt]

(resending from the proper address)

> JNI is the same; we're not taking it away, but we're helping the user be
aware of when a library is putting the integrity of the application at
risk, so that they have the ability to make a judgement call on whether
they are willing to trust that library.

My concern is that this is going to be GDPR cookie banners all over again,
or Proposition 65 warnings ("this Java application contains chemicals known
to the state of California to cause cancer"). Justifications like "user
awareness" and "conscious opt-in" strike me as weak when human factors like
alarm fatigue [1] are considered. The JEP states that "the last few years
have proven that the vast majority of code does not require breaking
encapsulation," and I think that's factual but not truthful: almost all of
the real-world JDK8 *applications* I've seen needed flags like
`--add-opens` in order to upgrade to JDK11+, and to the best of my
knowledge the use of JNI is also near-universal, at least at my company. Is
integrity-by-default still worth doing if *every* real-world Java
application requires these flags?

I suspect the answer is: yes, but not for reasons of informed user consent.
Rather, the goal here is to incentivize the ecosystem to reduce its
dependence on JNI and other integrity-breaking features, similar to what
Windows Vista did by introducing UAC [2]. In fact, the JEP frankly
discloses this intention:

> Because deep dependency trees are common, the chances are high that an
application would unknowingly depend on an encapsulation-breaking library.
Consequently, if applications had to opt *into* strong encapsulation, few
would be able to do so. The platform must, therefore, exert pressure on the
ecosystem to minimize the proliferation of libraries that bypass strong
encapsulation by making strong encapsulation opt *out* rather than opt in.

I see the long-term wisdom of this, but I also find it a little grating
considering that JNI has done a lot to pick up the slack in making many
features available to Java developers: Unix domain sockets (pre-JDK16),
fast AES-GCM (pre-JDK9), and Intel SHA Extensions (pre-JDK9) come to mind
right away. If JNI is going to be *de facto* deprecated, it's reasonable
for Java developers to wonder how their needs will be met without it.

[1] https://en.wikipedia.org/wiki/Alarm_fatigue
[2]
https://web.archive.org/web/20080719165816/http://news.cnet.com/Microsoft-Vista-feature-designed-to-annoy-users/2100-1016_3-6237191.html

>
On Mon, Aug 28, 2023 at 9:39 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> I think you have a serious misunderstanding of what is being proposed
>
>> here.  Nobody is taking away JNI.  What is being taken away is the
>
>> ability to bury the use of JNI in a library where the user is unaware of
>
>> it.  By "user" here, I mean the person putting together a Java
>
>> application from a group of modules and JARs -- sometimes called the
>
>> "application assembler."  This user has a right to know what their
>
>> application is doing.
>
>>
> When we started to enforce the accessibility model in Java 9, we didn't
>
>> take away the ability to do deep reflection, we took away the ability to
>
>> do so _without the user knowing_.  The reason that the various
>
>> `--add-opens` are specified on the command line is so that the user has
>
>> a chance to consent to relaxed integrity.  JNI is the same; we're not
>
>> taking it away, but we're helping the user be aware of when a library is
>
>> putting the integrity of the application at risk, so that they have the
>
>> ability to make a judgement call on whether they are willing to trust
>
>> that library.
>
>>
>
> On 8/28/2023 11:37 AM, Constantin Christoph wrote:
>
>> >
>
>> > JNI is a fundamental part of the java ecosystem, and it shouldn't be
>
>> > restricted in a manner like this. It's a powerful, useful tool, and
>
>> > should be treated like that. Developers should have that option freely
>
>> > available.
>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230828/2e4ee8c4/attachment-0001.htm>