Why JNIEnv / JObject is not Send and how and I do an asynchronous callback?

[tisonkun]

lazy_static! {
    pub(crate) static ref RUNTIME: Runtime = Runtime::new().unwrap();
}

#[no_mangle]
pub extern "system" fn Java_org_tikv_tijkv_RawKVClient_connect0(
    env: JNIEnv, _class: JClass, pd_address: JString, client: JObject, f: JObject
) -> () {
    println!("0");
    let x = async move {
        let pd_address: String = env.get_string(pd_address).unwrap().into();
        println!("1 - {}", &pd_address);
        tikv_client::RawClient::new(vec![pd_address])
            .await
            .map(|c| {
                println!("2");
                env.set_rust_field(client, "nativeHandle", c).unwrap();
                env.call_method(f, "complete", "(Ljava/lang/Object;)Z", &[JValue::Object(client)]).unwrap();
                println!("3");
            })
    };
    RUNTIME.spawn(x);
}

this code snippet fails to compile because

1. client has type JObject<'_> which is not Send
2. env has type jni::JNIEnv<'_> which is not Send

[dmitry-timofeev]

Objects of both of these types can only be used in the thread where they were created. They can't be reused in any other threads.

I highly recommend reading the spec on that and the tips before doing multi-threaded JNI. Then you can consider using either Executor or attach_current_thread to get appropriate JNIEnv, and use GlobalRefs to share a reference between threads.

[tisonkun]

Thanks for your reply. Actually I'm thinking of the solution as

public static CompletableFuture<RawKVClient> connect(String pdAddress) {
        final RawKVClient client = new RawKVClient();
        return CompletableFuture.supplyAsync(() -> {
                connect0(pdAddress, client);
                return client;
        });
    }

and

let x = async move {
        let pd_address: String = env.get_string(pd_address).unwrap().into();
        tikv_client::RawClient::new(vec![pd_address])
            .await
            .map(|c| {
                env.set_rust_field(client, "nh", c).unwrap();
            })
    };
    let _ = block_on(x);

the Rust part of code is in async form which I cannot change. But in this way I'm afraid that whether a blocking call on native method will finally exhaust all threads and we are able to do nothing to kill the call?

[tisonkun]

Hi @dmitry-timofeev! I met the same requirement again today. And I'd like to know if the solution above is the best ATM. Since that it somehow blocks the execution, I'm afraid that we only provide an async API while the implementation is still blocking.

[tisonkun]

Here is an example to meet the original requirement:

apache/opendal#2291

A previous commit to save JNIEnv thread locally is significant also.