Robert Bragg

> Thanks for the invitation, I am an amateur and I can't take the responsibility of being a regular member of the `jni-rs` team maintaining an important library. no worries...

> If local frame management can be made unsafe, a Java callback function will probably not need an unsafe AttachGuard::from_unowned call in order to use the JNIEnv, and AttachGuard creation...

> Besides, the TODO comment in `AttachGuard::from_owned` code confuses me I think part of the confusion here is that I wrote that TODO note before changing `JNIEnv` to not be...

> I had considered seperating the frame counter from the nested-attachment counter, it is probably unnecessary; the attachment counter may be increased without pushing a local frame, and the frame...

For the sake of giving an update for where my iteration here has taken me, I've pushed some updates that: - Adds a getter for the global JavaVM singleton, via...

> If `JNIEnv` isn't going to be transparent any more, then there need to be big, conspicuous warnings for people migrating from previous versions, both in the changelog and the...

> One problem stands out: `extern fn`s to be called from Java need better ergonomics and safety. As of this PR in its current state, this involves a raw pointer...

> This change, as it stands, is a breaking change of the most severe kind: it will cause previously valid code to segfault or exhibit other undefined behavior, and the...

One thing I'm not sure of atm is whether it's really beneficial to have a dedicated wrapper type like `JNIEnvInherited` vs just using the `jni_sys` pointer type when it comes...

> Excuse me, I looked at the previous `AttachGuard::current_frame_env()` and get confused again about why it is impossible to be safe. > > > Rust can't force by-value types to...