GlueGen/JNI versus Panama

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

GlueGen/JNI versus Panama

Sven Gothel
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
  - <>
- GlueGen
  - <>


- 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 <>
- FFI <>
  - FFM (memory) <>
- jextract <>



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!