JVM Rust design stuff

This page draws a rough sketch of what the design for talking from a JVM language to Rust (and vice-versa) might look like.

Useful tools

• https://github.com/BrainiumLLC/cargo-mobile

Bindings

The following projects are interesting:

• https://github.com/nativelibs4java/BridJ
• https://github.com/java-native-access/jna
• https://github.com/MaulingMonkey/jni-bindgen/
• https://github.com/eqrion/cbindgen
• https://github.com/stepfunc/oo_bindgen/
• https://stepfunc.io/blog/bindings/ (which looks cool but has a weird license).
• https://getditto.github.io/safer_ffi/
• https://github.com/flxo/android-binder/blob/master/src/binder/binder.rs

cbindgen with bridj or jna could be one of the simplest approaches.

cbindgen can generate C++ bindings to Rust code, and then <swig.org> can generate Java/JNI bindings to those. Although bridj already supports C++, it's no longer maintained.

It was later theorized that we could go with j4rs and write a small generator, or have a Rust network process that communicates with the app through binder.

Portability concerns are addressed by doing more stuff on the Rust side.

After debating whether spinning up the Tokio runtime to perform blocking calls, and tear it down after it's done, would be feasible, the "obvious" solution popped up:

• Have one Rust thread dedicated solely to running the Tokio runtime.
• Communicate into and out of the async Rust through queues.
  • One queue in Rust. The JVM side posts a message which Rust eventually picks up and handles.
  • One queue in the JVM side. Anything Rust needs to send back is put in that queue.

How to deal with the asynchrony on the JVM side is left to see, however, it should always be possible to have an additional callback to "wake up" whatever future/event there is to indicate that a new message is ready to be picked up.

• note. There are some protocols that would deal with serializaton and RPC - for example grpc/protobuf, canpnp. grpc in kotlin is quite nice (https://www.grpc.io/docs/languages/kotlin/quickstart/), but in Rust is pretty verbose (https://blog.logrocket.com/rust-and-grpc-a-complete-guide/)

To serialize the messages options like ProtoBuf, Cap 'n Proto, or even TL were all considered.