[graalvm-dev] MIgrating JNI to @CFunction

[Galder Zamarreno]

On Mon, Sep 21, 2020 at 2:00 PM Christian Wimmer <
christian.wimmer at oracle.com> wrote:

> Hi,
>
> Why would you want to migrate from JNI to @CFunction? The low-level C
> interface can be useful when you write new native-image only code, but
> if you have a working JNI implementation that you can keep it.
>

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.

This transport has a load of classes that should be initialized at runtime,
e.g. io.netty.channel.epoll.Native.

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.

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.


> > If you have JNI code that you're trying to migrate to @CFunction
> > definitions, how do you know whether you're getting the bindings right?
> > Is there a way to disable JNI for a particular subset and see if the C
> > bindings are working? Or is there some other way to inspect this?
>
> JNI and @CFunction are never overlapping. As soon as you annotate a
> function with @CFunction, no JNI call stub is created for that function.
>
> -Christian
>
> _______________________________________________
> GraalVM-Dev mailing list
> GraalVM-Dev at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/graalvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/graalvm-dev/attachments/20201009/4d20a9cd/attachment.html