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!

+++