Support passing platform-specific native object about uniffi-rs

[paxbun]

BTW, I'm using JNA and JNI in the same dynamic library; at first, I modified the template so System.loadLibrary is invoked right after Native.loadLibrary is called, but later, I kept the template as original and directly accessed to JNI_GetCreatedJavaVMs to get the current process's JavaVM.

[coolbluewater]

Hi @paxbun, I also would like to pass JNI objects from Kotlin to Rust.
Do you have a fork of uniffi that implements this?

[paxbun]

@coolbluewater No, I didn't have any time to work on this... If you want features like this but have to pass few objects, you can just System.loadLibrary the same library and pass the JNI objects. I have an example for you: https://github.com/paxbun/GraphicsTest/blob/6ab7e5d8cdc2864653d91f6d7fa77924c27815d5/rust/src/lib.rs#L16-L39

This example passes android.view.Surface via JNI and UIView via a C function, and does the other things using UniFFI. Feel free to ask me about the example :)

Note that this example also uses the KMM UniFFI bindgen mentioned in my first comment, so you have to build the plugin manually, which is not merged to main yet. Clone the branch of the following PR: https://gitlab.com/trixnity/uniffi-kotlin-multiplatform-bindings/-/merge_requests/39 You can build it with ./gradlew :build-logic:gradle-plugin:publishToMavenLocal.

This plugin configures almost every environment variable you'd need, but I haven't tested it on Windows or Linux. Please let me know if you have any trouble building that plugin or the example!

I'm going to make a POC of this at least by July.

[paxbun]

I've been continuously investigating safer API design for this, but the existence of JNIEnv always brings me to something ugly or unsafe, which is thread-local but always required for practical use. This is the least ugly design I've come up with:

We need to put JNIEnv into a polymorphic object, which returns the underlying JNIEnv when called from a JVM and does nothing when called from other environments, such as Swift or Python. Since JNA does not support putting JNIEnv in a structure and modifying JNA to support it also does not make sense in the Java world, if we need to do this, the polymorphic object creation must be done on the Rust side, specifically in the scaffold.

For example, if a UniFFI function has a PlatformObject parameter, the scaffold for that function may look like this:

#[uniffi::export]
fn foo<'a>(env: uniffi::Env<'a>, platform_object: uniffi::PlatformObject) { ... }

pub unsafe extern "C" fn uniffi_my_package_fn_foo(
  env_identifier: u128,
  env: *const ::std::ffi::c_void,
  platform_object: *const ::std::ffi::c_void,
  call_status: &mut ::uniffi::RustCallStatus,
) {
  uniffi::rust_call(
    call_status,
    || {
      let env = uniffi::Env::new_unchecked(env_identifier, env);
      let platform_object = uniffi::PlatformObject::new_unchecked(platform_object);
      my_package::foo(env, platform_object);
    },
  );
}

and the Kotlin binding can call this function like uniffi_my_package_fn_foo(UNIFFI_IDENTIFIER_JAVA, JNIEnv.current, platformObject) and the others like uniffi_my_package_fn_foo(OTHER_IDENTIFIER, nullptr, platformObject).

Since env now has the identifier, functions like is_objc or is_java are all in uniffi::Env, not uniffi::PlatformObject.

#[uniffi::export]
fn foo<'a>(env: uniffi::Env<'a>, platform_object: uniffi::PlatformObject) {
  if env.is_java() {
    let platform_object = platform_object.into_inner() as jni_sys::object;
    ...
  }
}

But as you can see, this design forces the user to add an additional parameter when using a specific type of parameter, a new constraint that has never been in previous versions.