GraalVM native compilation issues
piotr-yuxuan opened this issue · comments
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
Hello 👋 Any news on this? 🤩
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.
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? :-)
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:
- JavaCPP ends up supporting both mechanisms
- GraalVM ends up supporting Project Panama, since it's the new way to do interop.
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.