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

[Ty Young]

On 11/29/19 10:52 AM, Maurizio Cimadamore wrote:
>
> 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).


To be clear, where does SystemABI specifically stand in all of this? Is 
the functionality that I need going to be publicly introduced as part of 
a higher level API down the road or is using the ABI the only way to 
access it?


>
> 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...) 
>

FWIW, I really think the module system should be the way to solve this 
problem. Something like:


`requires internal java.base;`


because, to be frank, this isn't that much different than the issue I 
raised earlier about the module system not being capable of selectively 
hiding methods/objects that are apart of a public API class(for whatever 
reason) but aren't supposed to be used elsewhere.


For example, as part of a high level abstraction, it might seem 
inappropriate to expose Pointer objects. So, what could be done is 
something like:


`internal Pointer<Integer> getIntegerPointer()`


...which will only show up *if* you opt in.


>
> Maurizio
>
>