GlueGen/JNI versus Panama

Julien threw in the following subject:

"Support Foreign Function and Memory API, a memory segment created with it should be usable instead of a NIO buffer.
It's not mandatory as you can create a NIO buffer from a memory segment in the meantime. If things go well, maybe this API will be suitable to do many things in Java without JNI. "

Our current solution using
- JNI
  - <https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/jniTOC.html>
- GlueGen
  - <https://jogamp.org/deployment/jogamp-next/javadoc/gluegen/javadoc/overview-summary.html>

Features

- Produces a static foreign function interface (FFI) binding to native functions exposed in libraries
  - At compile time, C header are compiled and Java and C code being produced
  - Resulting C code must be compiled for each platform
  - In our case, each platform also may use different API sets (Windows GDI, X11, ...)

- The static nature of this FFI is especially important to me, due to
  - reviewed and 'self determined' code path -> security
  - performance  

- The FFI binding can mostly be generated automatically w/o custom user code

- The FFI binding may use plain java memory (copy, pinning) or locked NIO memory,
  each has its own rights and pro and cons.

- GlueGen's StructAccessor allows mapping memory structures 1:1 from Java to native lang,
  i.e. providing a FFM (memory)

- C++ is not supported

- Java callbacks are possible with custom user code

++

OpenJDK Panama
- Project <https://openjdk.org/projects/panama/>
- FFI <https://github.com/openjdk/panama-foreign>
  - FFM (memory) <https://github.com/openjdk/panama-foreign/blob/foreign-memaccess%2Babi/doc/panama_memaccess.md>
- jextract <https://github.com/openjdk/jextract>

+++

Comparison

When I reviewed this project a few years ago,
it does look similar to GlueGen and JNI .. from the distance view.

I understand the 'idea' of having a dynamic FFI binding, taking off the heat of producing binary builds (?)

What I was missing here is the static FFI binding nature (see GlueGen above).
  - reviewed and 'self determined' code path -> security
  - performance  

Maybe I am wrong here and Panama (w/ jextract) can generate a static native binding
w/o too much overhead, deterministic and well performing code?

I will assume that the memory features are also
using current JVM mechanisms under the hood: pinning, copy or locked NIO.

I also read about the claim of 'JNI is dead' :)
Well, the OpenJDK is using JNI to implement all parts of the OpenJDK itself,
hence I dare to say this is shameless self advertising and extreme nonsense.

+++

If I would have funding to enhance GlueGen, I would tackle the following:
- Allow using a different API / function description (XML, etc),
  which better details input and output nature of arguments etc.
  - Example: OpenGL xml spec

- Add better support for Java callbacks

- Either update the ANTLR based compiler or use a clang frontend toolkit
  - I would prefer ANTLR .. but ..

- Add C++ support

+++

Open for discussions!

+++

Hello

Java 23 will be released in September 2024 and contains this change. JNI isn't dead but releasing memory on the native heap (allocated for the direct NIO buffers) even with sophisticated workarounds (or dirty kludges...) is becoming increasingly difficult whereas it's not an aspect that can be neglected (not only in games by the way). Moreover, I'm not sure that a "smart" bridge between java.nio and java.foreign will remain and maybe it will be more convenient on the long term to expose a part of our public APIs with explicit support of both java.nio and java.foreign. Martin succeeded in going somewhere, it would still be a good source of inspiration.