JEP draft: Prepare to Restrict The Use of JNI

[Alan Snyder]

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?

If not, I can imagine developers responding to this change by adding boilerplate command line arguments to their build scripts
or sticking with old versions of the JDK (or maybe switching JDK vendors?).

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.
I suppose some application developers will experience improved confidence, but that confidence is warranted
only if their test code coverage is high enough to trigger the warnings/crashes during testing. That is not
a sure thing, especially when JNI is used to work around a JDK issue, which might be an isolated situation.

> This JEP, that doesn’t restrict JNI but only warns will allow us to further evaluate our options and their cost/benefit based on real usage feedback rather than speculation, in our usual careful and considered way.


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.
Something similar for finding “bad JNI” could be useful, although it is not clear that there is much “bad JNI” to be found.

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