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

[Ron Pressler]

> On 2 Sep 2023, at 16:18, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> It seems to me that the only way the proposed flags/warnings/future errors will improve the “integrity” of the JDK is if they somehow
> persuade developers to stop using JNI. Is that plausible?

Please read the relevant JEP: https://openjdk.org/jeps/8305968

Briefly, integrity by default reduces the ability of any fifth-level transitive dependency to make a decision that has a global impact on the application, such as potentially risking its portability, increasing the attack surface area, and precluding future optimisations, without the application’s author explicitly consenting to such ramifications. At the very least, the launcher configuration helps highlight whether there are areas that require closer scrutiny.


> If not, I can imagine developers responding to this change by adding boilerplate command line arguments to their build scripts

See the integrity JEP on the importance of an auditable configuration regardless of how it’s produced.

> or sticking with old versions of the JDK (or maybe switching JDK vendors?).

We’ve added similar future-change warnings several times over the past few years, and like this JEP, they’re all at the SE spec level, so all vendors must do the same.

> 
> The issue is whether there is an actual, practical benefit that justifies the hassle to developers and the risk of
> end users seeing scary warnings or experiencing future application crashes. I’m not sure there is.

That is perfectly fine. Having every user see the benefit of every feature is an unattainable goal (especially since one person’s benefit is another’s inconvenience). Nevertheless, if something is unclear in the integrity JEP you can point it out and we’ll try to clarify the text.

As for “future crashes”, that is not the subject of this JEP, but see the Future Work section. But apropos, note that unless they are modular, Java applications have always experienced such crashes if the launcher was not configured properly, with or without JNI. We’ve added a feature, modules, whose other goal beside strong encapsulation is preventing crashes due to an incorrect launcher configuration — namely "reliable configuration" (which is discussed in the JEP’s Future Work section). That feature has been available for some time to all those who are concerned about an incorrect launcher configuration causing such crashes. One reason why the Future Work is not immediately urgent is that it doesn’t appear too many people are too concerned about that, or prefer to use other mechanisms than those offered by the JDK. Anyway, there’s still time until a future restriction, but we best give people as much time as possible to prepare, so the sooner we warn about a future change, the better.

> 
> The goal of “gathering data” is completely different than the goal of “improving integrity”.
> In the past, there was a tool you could use to identify code that used “private” APIs.
> This was an “opt-in” solution. Developers didn’t have to use it. End users never saw it.

See the Future Work section of the JEP. That is insufficient, however, to provide integrity by default. BTW, end users never need to see the flag or the warning proposed by this JEP, either. We’re talking about a launcher configuration flag used by the application to configure the Java runtime, not a flag that needs to be added by the end user of the application.

> Something similar for finding “bad JNI” could be useful, although it is not clear that there is much “bad JNI” to be found.

https://mail.openjdk.org/pipermail/jdk-dev/2023-September/008182.html

> 
> (By usage feedback, do you mean developers complaining?)
> 

We mean learning what portion of users experience difficulty, what the extent of the difficulty is, and which aspects pose the most difficulty so that we could improve them.

— Ron