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

[Maurizio Cimadamore]

On 30/11/2019 07:30, Ty Young wrote:
>
> 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?

I'm referring to the API available here:

http://hg.openjdk.java.net/panama/dev/file/foreign-abi/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign

Moving forward, as described in the jextract document [1], this package 
will provide the basic knobs to access foreign memory and functions.

High-level APIs to model structs, pointers and other C/C++ might be 
defined (and targeted) by binder generators. But as for jextract, moving 
forward, we plan not to provide any higher-level abstractions, as doing 
so imposes a cost on all those users who don't need those abstractions 
(e.g. those who have their own wrapper types anyway).



>
>
>>
>> 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;`

This violates the very essence of using a module system. A module says - 
my API is made by these classes - but than if every client of that 
module gets to redefine what the boundaries are, why defining them in 
the first place? You have to understand that using --add-exports:foobar 
is no different than running with -Xverify:none - e.g. a deliberate act 
to switch off certain safety features of the Java platform. So, adding a 
command line flag, and writing an extra 'requires' on the module-info 
file, while similar on the surface, are rather very different steps. 
That said, again, I don't this it will be a service to anyone if this 
thread would to turn into another discussion about the goals of JPMS. We 
have other mailing lists for that.

Maurizio

[1] - http://cr.openjdk.java.net/~mcimadamore/panama/jextract_distilled.html

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