Native method binding

[Maurizio Cimadamore]

This is nice.

I'd note here that we started with something similar a long time ago and 
then we saw that if the JDK provided a low-level enough API, it would 
have been possible for other parties to provdie higher-level story (with 
annotations, etc.) which seems what you have done here.

I belive where I'm confused is here:

>
> But it would be nice to take the idea a step farther and get rid of 
> the interface altogether.

What is the problem with the interface?

Note that, alone, just calling via a native method won't help with 
platform dependency, as you will still need to "pick" a signature that 
is ok for _all_ platform, and adapt the method handle under the hood 
accordingly. So, in terms of "portability" interface vs. method is the same.

In terms of usability they are also the same: an interface method is 
just a method, checked by javac (and IDEs) -- same as a native method.

Is it startup you are worried about? If so, I agree, the cost model of 
JNI and FFM is very different, but I think we need a more holistic 
approach to address that. If my guess is incorrect, please expand more 
of why you think proxied interfaces are bad.

Maurizio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20241218/545a641e/attachment-0001.htm>