https://www.youtube.com/watch?v=kUFysMkMS00

I went into this talk expecting a talk on Remote Function Calls.

This talk, however, covers JEP-422, which is a better way to do JNI (Java Native Interface).

I had never directly worked with JNI before watching this talk. Therefore, it was outside my comfort zone and challenging while, at the same time, interesting to learn about the current limitations and future improvements.

I will most likely never have to interact with native code via Java. However, it is interesting to have such knowledge in your back pocket if needed.

I no doubt see third parties creating libraries that simplify the FFM API further via code-adding syntactic sugar.

The Current Solution - JNI

The current solution to calling libraries in another language is implementing a JNI adapter.

Java → JNI → Native Library

This may seem like a simple solution. However, implementing a JNI adapter involves implementing -

The above approach is expensive to maintain, while data transfer to and from the JNI method is cumbersome.

Data Transfer

In the current solution, data can be transferred via Direct Buffers, an off-heap memory accessed from the C/C++ code via JNI functions.

Unfortunately, there is no way to free or unmap this memory, and it is limited to 2Gb addressing spaces.

Frameworks

Several frameworks provide syntactic sugar around the development of JNI functions. However, these frameworks have limitations and can make deployments more convoluted.

JEP-422 Foreign Functions and Memory API