I am sort of surprised that there isn't a widely used tool that uses codegen to generate jni bindings sort of like what the jna does but at build time. You could go meta and bundle a builder in a jar that looks for the shared library in a particular place and shells out to build and install the native library if it is missing on the host computer. This would run once pretty similar I think to bundling native code in npm.

I have bundled shared libraries for five or six platforms in a java library that needs to make syscalls. It works but it is a pain if anything ever changes or a new platform needs to be brought up. Checking in binaries always feels icky but is necessary if not all targets can be built on a single machine.

The problem with the new api is that people upgrade java very slowly in most contexts. For an oss library developer, I see very little value add in this feature because I'm still stuck for all of my users who are using an older version of java. If I integrate the new ffi api, now I have to support both it and the jni api.

What I'm missing is a model for building/distributing those C libraries with a java application.

Every ffi example I've found seem to operate on the assumption that you want to invoke syscalls or libc, which (with possibly the exception of like madvise and aioring) Java already mostly has decent facilities to interact with even without native calls.

Compared to .NET's P/Invoke this is still way too convoluted. Of course Java has its own domain problem such as treating everything as a reference (and thus pointer, there is a reason Java has NullPointerException rather than NullReferenceException) and the lack of stack value types (everything lives on heap unless escape analysis allows some data to stay on stack, but it is uncontrollable anyway) makes translation of Plain-Old-Data (POD) types in Java very difficult, which is mostly a no-op with C#. That's why JNI exists as a mediator between native code and Java VM.

In C# I can just do something like this conceptual code:

```

// FILE *fopen(const char *filename, const char *mode)

[DllImport("libc")] public unsafe extern nint fopen([MarshalAs(UnmanagedType.LPStr)] string filename, [MarshalAs(UnmanagedType.LPStr)] string mode);

// char *fgets(char *str, int n, FILE *stream)

[DllImport("libc")] public unsafe extern nint fgets([MarshalAs(UnmanagedType.LPStr)] string str, int n, nint stream);

// int fclose(FILE *stream)

[DllImport("libc")] public unsafe extern int fclose(nint stream);

```

So much less code, and so much more precise than any of the Java JNI and FFI stuff.

Does this mean that one can use SDL2 together with Java without bending over backwards?

Wonder if this will make JNA (Java Native Access) redundant at some point: https://github.com/java-native-access/jna

Very useful, especially the prebundled platform bindings.