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

[Maurizio Cimadamore]

On 01/12/2019 01:45, Ty Young wrote:
>
> On 11/30/19 4:40 PM, Maurizio Cimadamore wrote:
>>
>> 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.
>
>
> Ah.I was a little confused because the location of SystemABI.java is 
> completely different on the "foreign-linkToNative"(what i've been 
> using) branch compared to the "foreign-memaccess" branch on Github. 
> Are there any plans to create a meta branch where everything is 
> included? I see a really old branch called "everything" on Github, 
> could that maybe get updated?
I think eventually, we will do that, but your idea of _everything_ and 
ours (outlined in the writeup I've sent) seem to differ. Moving forward, 
we will create a new foreign-jextract branch which will be based off 
foreign-abi and add the minimal jextract/API bits. After we get that 
branch in good shape (e.g. we can support all the use cases/examples we 
can support now) we will gradually phase-out the 'foreign' branch (and 
hence also the 'foreign-linkToNative' branch.
>
>
>>
>> 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).
>
>
> I'm a bit confused here... java.foreign(what I assume you're talking 
> about, since that's the API you use with jextract bindings) already 
> provides struct/pointer "models".
>
>
> Is not providing access to a common, shared way to define objects a 
> good idea? Wouldn't it just result in people defining things like 
> Pointer half a dozen times?

The problem is that public APIs already _have defined_ abstractions such 
as Pointer a dozen times (see my writeup) and with rather different 
characteristics too. As for structs - adding a common super-interface 
doesn't really add all that value - at the end of the day, jextract 
needed to generate the concrete struct interface for each particular 
struct that was encountered in the parsed headers. The bigger problem is 
that creating bindings for a native library is a complex, creative 
process with some bits of mechanical work in it. With the current 
jextract we tried to automate it all - and this resulted in some API 
choices being made for you by the tool; if you want/need to back out 
from some of these choices (and many existing bindings will need to do 
that), you need an infinite set of control knobs to tell jextract what 
to do - and this doesn't scale.


>
>
>> 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.
>
>
> The "very essence" of the module system was undermined already by the 
> command line argument overrides. That ship didn't sail away, it 
> instantaneously teleported.If people want access to something they 
> need(AKA unsafe), then they're going to ignore API boundaries 
> regardless of what you(as the API dev) want.
>
>
> Looking at the module system as some definitive way to keep people 
> from getting access to things they shouldn't is, IMO, wrong. It's a 
> way define the boundaries, not enforce them. In the past(pre java 8), 
> there was no easy, obvious way to tell what what was internal and 
> public. The module system fixed that and now people know.
>
>
>> 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.
>
>
> I thought it could be used to solve the problem you brought up. If one 
> project for whatever reason might require something in another first, 
> is it not policy to discuss it where relevant?
>