[foreign] jextract, distilled

[Ty Young]

I understand that this API is more for lower level memaccess usage, but 
personally I feel like a jextract API could be useful in general for 
just generating and validating bindings from within Java.


Such issues IMO with jextract are:


A. Command line can be very long and error-prone as each argument can 
just blend in with each other in more complicated bindings commands.


B. There is no way to generate bindings that are guaranteed to work for 
all platforms(and sub-platforms, like Linux distros). Generating 
cross-platform bindings really sucks and sometimes requires a different 
OS than what the bindings are intended for.


C. There is no way(AFAIK) to reverse validate(in other words, after the 
bindings are generated) the validness of bindings produced by jextract. 
If the bindings are broken for some reason you can't, as a higher level 
API dev, provide any information as to why it's broken or even know that 
the bindings are broken until it's too late.


Both A and B can be fixed with an interface API for defining the correct 
way to generate the required bindings and a way to execute that 
interface implementation from within Java. C could be fixed by providing 
a way to get the way the bindings where originally generated via meta data.


Could this maybe be added?



On 11/22/19 10:14 AM, Maurizio Cimadamore wrote:
> Hi,
> as we got foreign memory access and foreign function access on a much 
> more solid footing --- using VarHandle and MethodHandle, respectively 
> --- I thought it was time to look again at jextract and see how we 
> could make these new primitives play a more central part in the 
> extraction process. The writeup below captures my thinking on this topic:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/jextract_distilled.html
>
> Cheers
> Maurizio
>
>