JNI bindings to java

[g-ferrer-sk]

For andriod apps. Here it should be better clarified which applications exactly can be used in this context.

[anastasiia-kornilova]

To use auto-generation tools for providing bindings we need to provide an interface with std-types instead of Eigen types. After discussion with @g-ferrer-sk , that will be some cut subset of the current module interface.

Why would we like to use auto-generation? In that case all type conversions of functions and objects are in the responsibility of the tool that generates bindings, no need to manually track all changes in new functions and their signatures.

Candidate tools. JavaCpp, Scapix, hope that @pmokeev could provide below detailed comments on review about all possible tools.

So, there are three steps regarding this task

• Define a list of interfaces with std-types
• Support those interfaces in mrob
• Provide bindings for those interfaces

[pmokeev]

In total, several tools were considered to integrate the library into an android application:

• Original JNI good guide to using it

I think it is convenient to use this tool if you need to write one or two functions in C++, but nothing more.
It has a number of disadvantages, such as:

1. It is inconvenient to write code in C++, because you need to cast types between JNI and C++ every time JNI Types . The developer will have to do it on their own, which significantly slows down development.
2. The original JNI generates a .dll / .so / .dylib file of the library, from which functions are called in the future. We'll have to take over the generation of the desired type of library.
3. The developer assumes the responsibility to connect the library on his own every time through the System.loadLibrary. Sometimes you can forget to do this, and you will not be able to immediately figure out what the matter is.

There are a lot of usage guides for this tool, so everyone can use it if they want to. This tool does not suit us, just look at the first disadvantage.

• Djinni GitHub repository

The tool is good enough. Generates a bridge from an interface file. The developer must write the interface himself in the IDL file, which will then be used to create the library.
Let's start with the advantages of this tool:

1. Does not generate a .dll file, which gives us cross-platform functionality from the start. The bridge functions thanks to auto-generated .cpp files.
2. The library is written in native C ++, without JNI Types admixture.

Disadvantages:

1. Since the header file is generated from the IDL file, the developer must regenerate the interface on his own when making changes. There is an idea that this can be automated thanks to CMake, but in practice I haven’t tried this yet.
2. The tool is closed by Dropbox, and is supported by enthusiasts. It is difficult to predict how long this instrument will remain afloat. Consequence of this: there are few tutorials on using Djinni.

As a conclusion: the tool is good enough and can be used, but we would like to achieve more automation of the process.

• SWIG link

SWIG has put together part of the original JNI and part of Djinni. It also generates an interface using a special file like Djinni, from which the first disadvantage written in the block about Djinni follows. In addition to this, SWIG generates a .dll / .so / .dylib file (like original JNI), as a result of this we need to use something additionally (generate a library for a specific platform yourself).
But it has several advantages:

1. The tool is actively developed and supported by both developers and the community. There are a lot of tutorials on its use on the net, which makes the tool accessible.
2. SWIG has the widest range of bridging generation for different languages out of all presented here. Namely, he can do C#, D, Go, Guile, Java, JS, Lua, MzScheme / Racket, OCaml, Octave, Perl, PHP, Python, R, Ruby, Scilab, Tcl / Tk.

But unfortunately we cannot use it because of the .dll / .so / .dylib file.

• Scapix GitHub repository

This is the first of two tools that really interest us. Let's consider it in detail, let's start with the good ones:

1. The bridge is generated without .dll / .so / .dylib files. It does it on its own, and we don't have to think about what platform exactly we need to generate the library for.
2. The library can be written in pure C ++, Scapix will generate the necessary files (without sacrificing cross-platform) so that we can use the methods in our application. Generation occurs when the application itself is built (for example, in AS).
3. The tool is developed by one person who is very active in answering community questions.

But there is a significant disadvantage: In order for us to use methods from our library, we must include a header file in the source file, and inherit the file from some class. Unfortunately, we cannot connect the library via submodule, we will have to change the source files. A question on this topic was asked to the developer, while we are waiting for his ideas on this matter. If this is not important for us, then this tool is perfect for our task.
Scapix also generates a bridge for all possible platforms. But as the developer replied, this does not greatly affect anything.

UPD 30.08.2021 : The developer's answer is that he is working to ensure that the library files can be left unmodified. This will take a couple of weeks.

• JavaCpp GitHub repository

So far, this tool looks the most promising of all those previously presented.

1. Firstly, it takes all the advantages of Scapix in itself.
2. Secondly, the community is actively developing the tool.
3. And finally, the most important plus, what was missing in Scapix - we don't need to modify the source files. Here is a great example of how using this tool you can integrate the library into an android application. All actions take place in the build.gradle and CMake file.

At the moment, this looks like the most attractive option.

It is also worth mentioning for which platforms this or that tool is capable of generating bridges:

• Original JNI : Java
• Djinni : Java, Objective-C, C#, Python
• SWIG : C#, D, Go, Guile, Java, JS, Lua, MzScheme / Racket, OCaml, Octave, Perl, PHP, Python, R, Ruby, Scilab, Tcl / Tk
• Scapix : Java, Objective-C, Swift, Python, JavaScript (WebAssembly), C#
• JavaCpp : Java