Robert Bragg

Hi @OlegTheCat yes there were some breaking changes made with 0.21 for the sake of improving safety. If you haven't seen it yet you may want to check this [0.21-MIGRATION](https://github.com/jni-rs/jni-rs/blob/master/docs/0.21-MIGRATION.md)...

In terms of documentation the `JNIEnv` documentation was updated to cover this, instead of it being documented per-method. Here's the section that talks about `&mut self` vs `&self`: https://docs.rs/jni/latest/jni/struct.JNIEnv.html#self-and-mut-self Maybe...

Right, this is an unfortunate side effect of the changes made for 0.21, sorry about that. More than once now I've found myself compare this project to a game of...

Perfect, yeah that's the kind of thing I'd been imagining but hadn't considered the idea of making it a trait like this. I wasn't sure off the top of my...

> And yes, it uses `catch_unwind` and `AssertUnwindSafe`. It's not actually unwind-safe—it's definitely possible to observe invalid state in Java object fields after an unwinding panic in Rust—but because Java...

The discussion here was one of things I had in mind when working these changes to the low-level macros we use for making JNI calls, to simplify them, and (imho)...

Ah, tricky. Yeah the implementation seems to try and mirror how the C API lets you redundantly call `AttachCurrentThread` and it will be a NOP that just return the `JNIEnv`...

For reference also see this recent discussion around the soundness of APIs that return a `JNIEnv` here: https://github.com/jni-rs/jni-rs/discussions/436#discussioncomment-5421738

Thanks for looking at reproducing that issue. I just tried reproducing with a test like: ```rust use jni::{InitArgsBuilder, JNIVersion, JavaVM}; fn main() { let jvm_args = InitArgsBuilder::new() .version(JNIVersion::V8) .build() .unwrap();...

Just trying with openjdk 17 (with a relative path like): ```rust let jvm = JavaVM::with_libjvm(jvm_args, || { Ok(PathBuf::from("./jdk-17.0.1/bin/server/jvm.dll")) }).unwrap(); ``` is also currently working ok for me.