[EMAIL PROTECTED] writes:
> which values does the JNI spec say can be cached?
jfieldID's and jmethodID's. See page 17 of the JNI spec. "Accessing
Fields and Methods". As long as you keep a live reference to the
underlying class, the VM ensures that your jfieldIDs and jmethodIDs
are valid.
See http://java.sun.com/javaone/javaone98/sessions/T410/cache1.htm and
http://java.sun.com/javaone/javaone98/sessions/T410/cache2.htm, for
where the JNI group specifically tells people to cache their IDs,
because "Name Lookup Is Slow".
Most books that cover JNI probably teach this technique as well.
> The JNI was written so that there are no direct memory accesses to
> java objects/classes/fields/methods.
Since IDs are opaque, a VM could check to see if a cached ID is valid
for a particular VM, if it's not, then the VM could magically fix it.
Oh, did I mention that Sun also commonly stores static C references to
jobjects? :)
In order to be fully compatible with existing JNI code, code like the
following needs to be supported:
static jclass string_clazz;
void init_static_stuff(JNIEnv *env, jclass clazz) {
string_clazz = (*env)->FindClass(env, "java/lang/String");
string_clazz = (*env)->NewGlobalRef(env, string_clazz);
}
See page 14. "Global references remain valid until they are
explicitly freed."
See http://java.sun.com/javaone/javaone98/sessions/T410/refs2.htm for
where the JNI group explicitly tells people that this is allowed, and
is a good coding practice.
--
Paul Fisher * [EMAIL PROTECTED]
