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

[Ron Pressler]

> On 23 Aug 2023, at 13:57, Florian Weimer <fweimer at redhat.com> wrote:
> 
> * Ron Pressler:
> 
>> In other words, our proposal is: In the future, code that uses JNI
>> will run only if unsafe native access is enabled, and to prepare for
>> that future, JDK 22 should spotlight the use of JNI with
>> warnings. We've published a draft JEP that explains why using JNI is
>> unsafe and describes the warnings [3].
> 
> Is there a practical difference between the explicit flag, and tracking
> and reporting taint flags in crash dumps (and perhaps other places in
> the future)?

I’m not sure I understand your question (I believe “taint flags” are a Linux-kernel term?), but in the future it may be worthwhile to address the “reliable configuration” aspect and not just the “strong encapsulation aspect”, but the latter is more urgent, and the former will only matter in practice as more code is modularised. Even if and when we do that, there’s not much more we could do about code on the classpath that is very dynamic in nature (i.e. the Java runtime performs no analysis — that wouldn’t be possible to do in a sound way, anyway — for code on the classpath).

Just note that native code in general and JNI code in particular could subvert Java’s integrity in ways that are unrelated to crashes or other undefined behaviour. For example, JNI code can call encapsulated Java methods. The effect of that is not something that could be easily determined, nor necessarily exist at all in a running program. It could “just” make the program non-portable or vulnerable in some ways.

— Ron