<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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?<br>
</p>
<p>Jorn<br>
</p>
<div class="moz-cite-prefix">On 17-12-2024 18:12, David Lloyd wrote:<br>
</div>
<blockquote type="cite" cite="mid:CANghgrSgKGF9wrTX_My5YkUooUNAkKS53JNvHSzEmZY6W_+ryA@mail.gmail.com">
<div dir="ltr">
<div>
<div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div>
<br clear="all">
</div>
<div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">What do you
think?</div>
</div>
</div>
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">- DML • he/him<br>
</div>
</div>
</div>
</blockquote>
</body>
</html>