GraalVM native compilation issues

[piotr-yuxuan]

Hello, thanks for this great project.

I've notived that as of now it seems impossible to properly use caesium in a native binary compiled by GraalVM. As you sound way more knowledgeable that I about JNI and all things native, would you have any thoughts on this?

Here is a minimal reproducible code: https://github.com/piotr-yuxuan/caesium-mwe

[piotr-yuxuan]

Hello 👋 Any news on this? 🤩

[lvh]

Heya: sorry, I don't really have time to work on this feature.

FWIW: I think the issue is that GraalVM doesn't support JNR at all, and that's what we use to bind.

Two possible solutions:

• GraalVM learns how to support JNR (tricky but possible--effectively they'd have to do the Java equivalent of what libffi does)
• caesium uses JNI, e.g. via JavaCPP, instead.

[piotr-yuxuan]

No firm commitment on me, but how would you consider a PR about moving caesium to JNI? Would you have any guidelines or brief work description / steps to give as general advices? :-)

[lvh]

I think a move to JavaCPP would be super interesting especially if we can somehow maintain a semblance of API compatibility. If not, that sounds like a largely separate project.

oracle/graal#885 is an important issue here since it explains how JavaCPP, Project Panama and JNI relate. Unfortunately it's hard to predict how native-image is going to evolve, but it seems likely that:

1. JavaCPP ends up supporting both mechanisms
2. GraalVM ends up supporting Project Panama, since it's the new way to do interop.

[lvh]

FYI just to update this ticket: it seems like JDK17's native support (aka Project Panama but more specifically the JSR 412 API) might be a useful contender too, since it basically gives us JNA/JNR convenience but it's the runtime's problem to make it work. I don't know yet the degree to which GraalVM native-image (will) support it.