Auto-generate native Java-interfacing files about jni-rs HOT 3 OPEN

For a similar reason I ended up writing https://github.com/viperproject/jni-gen (undocumented...)

Our approach inspects the JVM by reflection at Rust's compile time and generates wrappers for methods listed in a whitelist in build.rs (see here for an example). We introduced the whitelist because we choose to generate a wrapper for every inherited method, thus increasing a lot the size of the generated code. Whenever possible (that is, unambiguous) the user can leave a field empty to let the generator choose the only possible name/signature/...

An example of the generated bindings: https://viperproject.github.io/prusti-dev/viper_sys/wrappers/index.html

Some problems that we found:

• Java methods can be overloaded. How to choose the corresponding name in Rust?
• Java method names allow more characters than function names in Rust. How to translate them?
• How to handle inherited Java methods? Should the user know what is the base class that implements it, or should a wrapper be generated in all inheriting classes?

The end result works fine, but there is a lot that can be improved. For example, the whitelist in build.rs may be intimidating at a first glance, the name of the method parameters is not preserved, and so on.

from jni-rs.

Federico, thank you for sharing your experience!

Just to avoid any confusion: are you talking about the opposite use-case -- creating native proxies of Java objects? I think that deserves a separate issue, it would be great if you submit one! There might be something the library can provide to ease that task.

We actually have both use-cases, yours on smaller scale, just a couple of hand-written proxies. They look like this:

// Pseudo-code
struct JavaFooProxy {
  // A global reference to the Java object.
  foo: GlobalRef;

  // An abstraction that allows you to execute some code with JNIEnv in a thread-safe manner.
  //
  // How it provides a context (JNIEnv) -- is an implementation detail.
  // For example, there might be implementations that:
  //   - Always attach/detach threads, which is VERY costly.
  //   - Keep a couple of attached threads and pass the lambda to them,
  //   - Rely on the fact that your app never creates more than N threads 
  //     and never `detach` them (a benign leak).
  //   - For local references: use JNIEnv directly.
  executor: Executor;
  
  // Calls a Java `Foo#bar` method.
  def bar() {
    executor.with_context((env: JNIEnv) -> {
        env.call_method(foo, "bar", BAR_SIGNATURE, …);
    }
  }
}

Regarding method name translation, you might find useful the JNI rules (that's the opposite use-case, but there might be some solutions that you may re-use): https://docs.oracle.com/javase/9/docs/specs/jni/design.html#resolving-native-method-names

from jni-rs.

Oh, I got it the other way around. Yes, I meant creating native proxies of Java objects. I just opened an issue to track it (#82).
Thanks for the suggestions!

from jni-rs.