Robert Bragg

Thanks for looking a this. I can't currently see any major reason to not try and support no_std if it looks like the jni crate currently doesn't have a strong...

Thanks for the clarification. I'm not sure if you're looking at publishing to the Google Play store, but one other thing that seems relevant here is that the Google Play...

```rust let env: jni::AttachGuard = env.deref(); // jni::JNIEnv AutoLocal> { let env: jni::JNIEnv:: = env.new_string("a").unwrap().into(); env.auto_local(obj) } static VM: std::sync::LazyLock = std::sync::LazyLock::new(|| { jvm().clone() }); let mut outer_env = VM.attach_current_thread_permanently().unwrap();...

Incidentally, when I've started looking at reproducing this - I was finding that it wouldn't crash, while I was testing against `jni-rs` from Git - where as it did crash...

I'm not confident I understand the original source of the crash currently - the crash doesn't seem to be directly related to dropping the `AutoLocal` - and it might just...

I think the original crash is related to thread attachment via `AttachGuard` handling somehow. If I move `let mut env = jni_get_vm().attach_current_thread().unwrap();` in the original test to the top of...

For reference here's another implementation of `test()` that's considered "safe" with JNI 0.21 that doesn't need to use `DerefMut` to give an `env` an arbitrary lifetime that allows the function...

Another thing that points towards a bug with `AttachGuard` is that if `test()` uses `std::mem::forget()` to forget its `AttachGuard` before returning then that also avoids the crash.

> My previous understanding is that dropping the `AttachGuard` may detach the thread from the JVM, thus having a local reference that outlives the guard is a UB. (Actually, the...

I've tried to give the issue a more specific title that describes why a crash is seen here