[foreign-abi] minimizing the surface of restricted native access

[Maurizio Cimadamore]

On 29/11/2019 12:27, Jorn Vernee wrote:
> Are there any plans to make jdk.internal.foreign a default export? 
> Currently it's one of the seemingly very few "internal" modules that 
> aren't exported and I'll have to recompile from source with it 
> exported in order to use it. 

What Jorn said is valid in general. With respect to the specific case of 
foreign API, I think the strategy would be to gradually move 
functionality out of ForeignUnsafe (since we have found a couple of 
_safe_ tricks which allow us to make some of the methods in there safely 
accessible).

There will be few 'unsafe' operations - and those will be, eventually, 
part of the public API, but you will need some kind of opt-in, at 
run-time, to be able to call them. As discussed in a previous thread (I 
would not like to rehash the entire discussion in there), we might 
consider doing something along these lines for JNI too (mechanism TBD - 
I'll share more details as soon as we have detailed enough plans).

In other words (and, to summarize) the presence of ForeignUnsafe in a 
non-exported package is caused by the fact that (i) we didn't try hard 
enough to make some of the operations in there safe (now we know how to 
do that) combined with (ii) a lack of a way to be able to say "yes, I 
really do want to access native code" (we will need a story for that).

I would expect that, moving forward, 'restricted native' methods will be 
marked in the public API in a similar way to what with do with preview 
methods - example:

https://download.java.net/java/early_access/jdk14/docs/api/java.base/java/lang/String.html#formatted(java.lang.Object...)

Maurizio