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

[Ty Young]

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?


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


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