Native method binding

[Jorn Vernee]

It's an interesting idea, but I'm not sure which use cases it would 
address. If the main goal is reducing the amount of boiler plate code 
that a user has to write, then we already have a solution for that: 
jextract. The JDK mostly just provides the low-level building blocks, it 
is jextract which provides a higher level API, and does all the 
mechanical work of figuring out how to link a native function, given a C 
header file.

JNI's RegisterNatives allows a user to bypass the JDKs method of linking 
native methods, and implement their own. I'm not sure I see a similar 
benefit in the case of FFM though. With FFM, the user is already in 
control of the linking process.

I understand that there might be a desire to wrap a downcall method 
handle produced by the linker into a higher level view, but there are 
already several other solutions to do that: jextract as mentioned, or 
for instance MethodHandleProxies, as mentioned by Maurizio, or you could 
even use a Java agent to replace the implementation of a native method 
with one that calls a linker-produced method handle.

There may yet be other tools that will expose FFM through their own 
flavor of high-level view. Jextract is just one such tool, and, as a 
result of looking at various trade-offs, that is the tool we ended up 
writing to support the low-level FFM API found in the JDK. If you think 
it is not sufficient, I'd like to understand why. Is there a use case 
you have run into that can not be addressed by jextract?

Jorn

On 17-12-2024 18:12, David Lloyd wrote:
> With the (hopeful) ascendance of FFM over JNI, what about the idea of 
> allowing `native` methods to be bound to `MethodHandle`s on the Java 
> side at run time? This would allow for a much nicer experience than 
> creating wrapper methods and would bring another level of parity with 
> JNI, which has this capability (`RegisterNatives`). The capability 
> could be restricted as a form of native access, and only allowed for 
> methods in classes within the same module.
>
> What do you think?
>
> -- 
> - DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20241218/d080c44f/attachment-0001.htm>