JavaCPP VS JNA

Here is the code for JNI, which uses the prebuilt JavaCPP library to call the getpid function. We don't have to write all the manual C binding code and rituals as the JavaCPP library already does it.

Javacpp is the best ffi library of all https://github.com/bytedeco/javacpp

As for our approach, we maintain a library called javacpp: https://github.com/bytedeco/javacpp which proves a python wheel like experience where we distribute natively optimized c/c++ code (and even cuda accelerated code) as jar files on maven central. We also are able to develop with a python like experience by passing pointers around and other low level constructs directly allowing optimizations that you typically only get in c/c++.

https://github.com/bytedeco/javacpp

* it maps naturally and efficiently many common features afforded by the C++ language and often considered problematic, including overloaded operators, class and function templates, callbacks through function pointers, function objects (aka functors), virtual functions and member function pointers, nested struct definitions, variable length arguments, nested namespaces, large data structures containing arbitrary cycles, virtual and multiple inheritance, passing/returning by value/reference/string/vector, anonymous unions, bit fields, exceptions, destructors and shared or unique pointers (via either try-with-resources or garbage collection), and documentation comments*

I did not try myself, but for JNI maybe this could make lives easier? https://github.com/bytedeco/javacpp

In case you haven't used it (assuming that you already know about JNI, for comparison) - https://github.com/java-native-access/jna is about as easy as it gets for native interop. Also, as mentioned in another comment, with the Java FFM (Foreign Function and Memory) API already in preview mode, pretty soon, there will be no external dependencies at all, and Java should be able to interop with any language that can talk to C.

The complexity of JNI has given rise to some community-driven libraries that make it simpler to do FFI in Java. Java Native Access (JNA) is one of them. It's built on top of JNI and at least makes FFI easier to use, especially as it removes the need to write any C binding code manually and reduces the chances of memory safety issues. Still, it has some of the disadvantages of being JNI-based and is slightly slower than JNI in many cases. However, JNA is widely used and battle-tested, so definitely a better option than using JNI directly.

This is about calling into any native operating system APIs, as long as they are callable via C or C++ (which these days means "all" operating system APIs).

JNI is somewhat harder to use, because you need custom glue on both sides of the border: Some custom classes in Java and some custom code on the C (and C++) side.

This proposal would remove the need for the glue on the C side and would allow a pure java solution.

Something like this has existed in third-party form for a while as JNA (https://github.com/java-native-access/jna), but now it's going to be built into the JRE itself (if the proposal passes through review)

I use JNA https://github.com/java-native-access/jna , as you can write the entire interface in Java faster as well as easier without the need of messing with the complexities of JNI.

This (still someone else's code) will give you access to low level operating system APIs. For example, this will let you interact directly with the Windows COM, which lets you define interfaces and implement them: https://github.com/java-native-access/jna

.. and probably with JNA: https://github.com/java-native-access/jna

ODBC is a C API. You would need to make C calls from Java. You can use JNI or JNA to access native code.

Go to https://github.com/java-native-access/jna and download both "jna-5.8.0.jar" and "jna-platform-5.8.0.jar"