JEP proposed to target JDK 22: 454: Foreign Function & Memory API

[Maurizio Cimadamore]

>
> What has been attempted to communicate is something very different: 
> there are plentyful of Java programs that have no application package 
> defined for them and do not have a launcher that would set that flag 
> for them.
>
> For this group of people the warning will be quite shocking as it 
> states that using the Java programs has become dangerous, so dangerous 
> that it is even planned to inhibit the use of those Java programs 
> sometimes in the future!
>
To be clear - the case you refer to is a bunch of Java classes (not a 
jar, otherwise that would have been addressed) that is executed via some 
`java -cp ...` (where `java` is some suitable installation that is 
provided to the client).

This has already been discussed - alternatives have been proposed (such 
as the use of jlink), but not much progress has been made. Again, I do 
not think there is any value in rehashing these discussions here.


>>
> Yes, it is always possible - even without native access capabilities - 
> to create situations where programs behave destructively. In the case 
> of JNI one would look out from the beginning to not get into those 
> crashes - as probably experienced the hard way when learning C, C++ - 
> as otherwise the JNI library would be rendered useless.
>
> FFM is different as it becomes possible that non-C/++, pure Java 
> programmers may inadvertently cause crashes. But even so, such Java 
> programmers would not have read the FFM documentation as it 
> prominently warns about this, hence using FFM and not really knowing 
> what they do. This scenario is not one that one would expect from 
> professional Java programmers, would it?  And if a crash occurs it 
> cannot go unnoticed hence the immediate pressure to go after the 
> problem at which time all FFM related interactions that may cause a 
> crash would be checked upon.
I think your arguments boil down, for both FFM _and_ JNI to: I'm a 
library/application developer and I want to retain control of what's ok 
and what's not ok. If my code happens to use native code, then I (the 
library developer) take full responsibility of the well-formedness of 
that code, and all the other code that depends on my code should trust 
it too. While I see why you might prefer a world like that, the reality 
of Java deployment is at times much, much harsher - a single application 
can have hundreds of dependencies. In some environments it might be 
desirable to audit which of these dependencies are allowed to perform 
native access, and in others it might be preferrable to just disable 
native access. The only way to support all these cases, is to make uses 
of native code "bubble up" in the process, so that somebody else can 
have the final say as to whether that's ok or not.
>
>> In the current world, there is _no way_ for applications (e.g. pure 
>> Java ones) to guarantee that memory safety is not going to be 
>> compromised by any of their 3rd, 4th or 5th party dependencies. We 
>> would like to change that. The mechanism by which native access  is 
>> granted, while consistent with similar flags (e.g. 
>> `--illegal-access=permit`, or, more recently 
>> `-XX:+EnableDynamicAgentLoading`) might not be perfect, and we we are 
>> committed to make it better (see above). But we strongly believe in a 
>> world where native access requires an opt-in.
>>
> Then why not do the same for Java itself explicitly, i.e. the 
> application packager must also add e.g. java.base to proof that she/he 
> is aware of native access there?

With the JVM being written in C/C++, w/o native access in java.base your 
application wouldn't even be able to start. And, in general, the 
argument you are making is a bit hyperbolic - java.base also use Unsafe, 
and many other internal routines that are not necessarily available for 
outside. But that is not a reason for giving _all_ developers such blunt 
tools. I stand by what I said last time: we believe in a world where 
pure Java applications can enforce that no 3rd party native code ever 
gets executed (for the scenarios where that would be desirable).

I think you made your case (more than once!), and your feedback has 
given enough consideration (here and elsewhere). While we appreciate the 
dedication, in our experience these discussions have a tendency to make 
other developers feel less engaged, and less inclined to provide 
additional feedback. So, unless there is something fundamentally and 
qualitatively new to discuss around the topic of restricted methods and 
warnings, I'd suggest we agree to disagree.

Maurizio