JavaCPP VS JNA

JavaCPP and presets for working with JNI

In the meantime you might want to check out JavaCPP: https://github.com/bytedeco/javacpp

Maybe you can use JavaCPP?

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*

If you were prepared to go to the JVM you might try JNA. https://github.com/java-native-access/jna

Other good example, but for Java platform is JNA library. Do not mix it with Java's JNI, which is a bad example of how it could be done.

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

JNA looks reasonable for accessing native code from Java: https://github.com/java-native-access/jna/blob/master/www/Ge...

I was the de facto maintainer of JNA (https://github.com/java-native-access/jna) win32 bindings for years. The API metadata is welcome - we have always based all work on header files in the visual studio / windows SDK. Now there’s a change to generate that code - someone might want to try to replace hand crafted mappings in JNA with generated ones - there’s a huge test suite to work with.

In case you have existing low level code in C/C++ and you want to integrate it with Java, there's https://github.com/java-native-access/jna But it's fairly unwieldy to work with, and calls Java=>C carry an overhead, so you want as few of them as possible. Which in ROTP means you want to transport all the relevant data into your AI code, then do the processing on a handful of calls, then return the result. Alternatively, an option would be to export say savegame (or other data) as JSON, run your AI module as a separate process, and then write the results to another file. While ROTP at the moment cannot do JSON save games, I have begun looking into it.