Robert Bragg

> I'm afraid that this will be possible: right 👍

but yeah, going back to what I had been thinking previously - that thread attachment should be considered `unsafe` - then if we also had a Safety requirement similar to...

One of the really unsatisfactory outcomes from experimenting with making thread attachment unsafe, combined with taking a closure is that Rust doesn't give a practical way to make it `unsafe`...

Looking at addressing this issue, I'd be interested in your thoughts on these draft changes for re-working thread attachment @wuwbobo2021: https://github.com/jni-rs/jni-rs/pull/570 E.g. if I try and reproduce the original test...

I'm guessing you're specifically referring to the implementation of native methods like: ```rust #[no_mangle] pub extern "system" fn Java_HelloWorld_hello(mut env: JNIEnv, _class: JClass, input: JString, ) -> jlong { //...

For reference, this should be addressed to some extent by #570, because there is a new FFI-safe `JNIEnvUnowned` type for capturing the raw env pointer in native methods that needs...

Btw just to join the dots for posterity here - I think this issue somewhat overlaps with https://github.com/jni-rs/jni-rs/issues/441 _**edit**: actually it looks like it was found in the discussion above_

> Note that this issue also affects `WeakRef`. Thanks, yup. I've just updated the title to reflect that. For reference here, draft PR #570 currently includes draft changes for `GlobalRef`...

It's tricky to know the best place to drive this conversion (it's been touched on in many issues over the years), but I've just added a comment to this draft...

> Oops, sorry, I didn't realize that JavaVM::get_env() in the https://github.com/jni-rs/jni-rs/pull/555 draft version can still return the JNIEnv in case of the thread has already been attached. It's a bit...