Robert Bragg

Okey, I've just come back to take another pass at this... I've added a `JNIEnvUnowned` type that can be used with native methods (I went with "Unowned" instead of "Inherited"...

Okey, I've done a bunch of clean up, split a few things out into separate PRs (#595 and #596) and done a big re-write of the PR description with lots...

> > `JNIEnvUnowned::with_env()` also wraps the given closure in a `catch_unwind` to help ensure that native method implementations don't allow Rust code to unwind over the FFI boundary. > >...

> If it is Err, it contains the panic payload, and dropping that may in turn panic!" hmmm, yeah that's a good point - it'd probably be good to ensure...

> If it is Err, it contains the panic payload, and dropping that may in turn panic!". In the current `JNIEnvUnowned::with_env`, the panicking payload is probably dropped at the line...

Okey, I've gone ahead and landed these changes while I'm happy enough with the smoke testing I've done and am convinced this is a worthwhile re-design of the thread attachment...

As a first impression - yeah implementing a trait on your App state sounds like it could work pretty nicely - though the devil will probably be in the details....

For reference I'll probably actually close this while I realized after initially making this PR that we don't need a new release for the jni-sys crate itself we just want...

thanks for the tip. I think in this case it mainly just highlights the `load_data` is probably not the right tool for trying to include xml directly into a template....

Not yet but maybe that'd be the way to go - I'll give it a try - I think originally that just conceptually seemed like the wrong tool but maybe...