Native method binding

[David Lloyd]

On Wed, Dec 18, 2024 at 9:52 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> 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.
>
They're bad because they're a mis-fit. You end up creating a static field
holding a global singleton object of a class which is the single possible
implementation of the interface. That's what static methods are _for_. If I
designed a whole program that way, I'd be called crazy. :-)

--
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20241218/776e11dc/attachment.htm>