java-ffi-benchmark

Yes, I would have said JNI (and JNI still exists). But FFM is much more than a wrapper. In most situations it offers a significant performance boost over JNI. E.g. see https://github.com/Glavo/java-ffi-benchmark, which is a bit out of date, and FFM is even better now especially in the cases it was behind in those benchmarks. Also, the integrity story is different for them. JNI is able to arbitrarily call Java methods and read/write variables, bypassing Java's access control. FFM doesn't. So really, the only integrity issue with FFM is the native code's own memory safety. With JNI, there are bigger risks (e.g. JNI can mutate Java strings).

Declaring and calling a C method in C# is as trivial as [LibraryImport("my_library", EntryPoint = "pass_numbers")] partial static void PassNumbers(int a, int b, int c); For AOT compilation, you can even completely statically link[0] it into the binary and annotate with [SuppressGCTransition] - it will be as cheap as a direct call from C++ (although GC transition is just a helper stub call that is barely noticeable on microbenchmarks - 1-2ns difference at throughput). In fact, you can also do the reverse and AOT-compile C# projects to regular dll/libs which can be called from C, C++, Rust, etc. land with ease: [UnmanagedCallersOnly(EntryPoint = "receive_c_string")] public unsafe static void ReceiveCString(byte* ptr) { /* impl.. */ } (there are other aspects that make this a powerful combo like being able to wrap pointers