`JMethodID`/`JStaticMethodID` lifetime about jni-rs HOT 3 CLOSED

This is only a problem when you want to make the method/field id outlive the method it's obtained from, correct?

Correct.

It shouldn't be able to escape the extern method that where it first gets looked up, since the JNIEnv can't either.

Actually, it can. The JNIEnv object obtained by a JNI function can be kept in thread-local storage, and it can be used as long as that thread is attached to the JVM. That thread can also cache identifiers of methods and fields.

from jni-rs.

This is only a problem when you want to make the method/field id outlive the method it's obtained from, correct? It shouldn't be able to escape the extern method that where it first gets looked up, since the JNIEnv can't either. We might need something like you've got above in order to give out "Global" Method/FieldIDs.

from jni-rs.

Is there a better way to cache these rather than having to use std::mem::transmute()? At the very least classes are cacheable without an issue by using new_global_ref, but I kinda feel hacky having to std::mem::transmute() on these ones

from jni-rs.