Robert Bragg

> I guess a "safe" AttachGuard is possible if we could claim that any safe function (except TLS destructors) should not detach the current thread from JVM if it was...

> @argv-minus-one has told me that &mut JNIEnv requirement of JNI methods can be removed if soundness issues of the "safe" with_local_frame didn't exist (why is it required for all...

hmmm 🤔 I can't quite recall off the top of my head if it's important that we currently distinguish that mutable access is required for creating local references vs blocking...

hmm, wait I got confused - `with_local_frame()` already takes a mutable reference so my comments above don't make sense - I thought you were saying that `with_local_frame()` is currently taking...

> The Android implementation of https://github.com/rib/bluey uses get_env() heavily, how could it be changed to adapt the possible new API of jni-rs I think there were a number of JNI...

Btw is there some particular problem with the requirement to have a mutable `JNIEnv` reference for APIs that may create local references? Although we could potentially relax that constraint without...

> Would you like to check the "further changes are possible" section in my description for ? It's eliminating the need of creating local frames explicitly, however, one might think...

Okey, a lot of things were discussed in this issue but hopefully the changes in https://github.com/jni-rs/jni-rs/pull/570 have addressed everything. Notably, in the context of native methods there is a new...

I think I'll close this for now, while this issue went on too many tangents to really follow what it represents. I _think_ for the original question I would suggest...

Every time I try and think through closing up the soundness holes around JNI thread attachment I become convinced that the notion of supporting RAII auto-detachment guards is practically impossible...