I've got a JNI C DLL that responds to callbacks from a 3rd party DLL. From those callbacks, I want to call methods of a java object.
The java object instance is stored as a global ref.
The JVM pointer is captured in JNI_OnUnload().
AttachCurrentThread() seems to succeed and return a valid (i.e. non-null) JNIEnv* to the callback thread.
However, during the callback thread's code sequence, it calls pEnv->FindClass(...) and FindClass is returning null. The arg to FindClass() is a valid class path.
When I hack my code and explicitly call the callback thread's code sequence from another JNI function called from Java (i.e. it is passed a JNIEnv* as its first argument), the code sequence executes without a hitch. But when that same code sequence is called from the callback thread, it fails as described above.
What could be wrong with the JNIEnv* gotten from the callback thread calling AttachCurrentThread()?
Edited by: 988420 on Feb 16, 2013 6:31 AM
This turned about to be a java classloader issue like explained on https://groups.google.com/forum/?fromgroups=#!topic/android-ndk/2gkr1mXKn_E. The solution is to cache all needed jclass instances as global refs, and then use those global refs from the callback thread.
I suspect a better solution is to provide a 'root' which would either be a class loader or even a class. And that is accessible from a java global context.
Your JNI gets the root and from that is can get the class loader.