Administrator
|
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! +++ |
Free forum by Nabble | Edit this page |