<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><span style="font-family:Arial,Helvetica,sans-serif">On Mon, Sep 21, 2020 at 2:00 PM Christian Wimmer <<a href="mailto:christian.wimmer@oracle.com">christian.wimmer@oracle.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Why would you want to migrate from JNI to @CFunction? The low-level C <br>
interface can be useful when you write new native-image only code, but <br>
if you have a working JNI implementation that you can keep it.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">I'm not sure you can keep it as is in all cases. One example I've seen that cannot be integrated with existing JNI setup is Netty's epoll native transport.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">This transport has a load of classes that should be initialized at runtime, e.g. io.netty.channel.epoll.Native. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Now, to use Netty's JNI implementation as is, you also have to register JNI methods of that class at the native image build step, so that Netty's JNI's OnLoad() can successfully complete in netty_epoll_native.c file. Native image production dutifully complains that you're trying to reference a class that is meant to be initialized at runtime during build time.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">I've worked around this by duplicating static JNI method definitions as non-static methods and then hooking them in with @CFunction. This seemed to work fine in the test I've run.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> If you have JNI code that you're trying to migrate to @CFunction <br>
> definitions, how do you know whether you're getting the bindings right? <br>
> Is there a way to disable JNI for a particular subset and see if the C <br>
> bindings are working? Or is there some other way to inspect this?<br>
<br>
JNI and @CFunction are never overlapping. As soon as you annotate a <br>
function with @CFunction, no JNI call stub is created for that function.<br>
<br>
-Christian<br>
<br>
_______________________________________________<br>
GraalVM-Dev mailing list<br>
<a href="mailto:GraalVM-Dev@oss.oracle.com" target="_blank">GraalVM-Dev@oss.oracle.com</a><br>
<a href="https://oss.oracle.com/mailman/listinfo/graalvm-dev" rel="noreferrer" target="_blank">https://oss.oracle.com/mailman/listinfo/graalvm-dev</a></blockquote></div></div>