CNI namespace

Tue Apr 4 09:36:00 GMT 2000

Paul Fisher wrote:
> Per Bothner <per@bothner.com> writes:
>> > Paul sent me some private email, which didn't really explain the
> > idea. For one thing, I don't see how the JNIEnv can get passed.
>> Sorry for the delay in replying -- been sick of late.
>> The JNIEnv and jobject (this) is passed into a function from the
> foreign VM, so it's always around for calling member functions and
> accessing fields. When it's not possible to pass around the JNIEnv
> (ie. when calling a non-member function), it can be simply retrieved
> as thread local data. No changes to g++ should be necessary.
>
...
>> class Object
> {
> static jmethodID *method_ids;
>> jobject obj;
> JNIEnv *env;

You cannot store JNIEnv in an object, because this pointer is different
for each thread. So if two threads access the same object, CRASH.
In another end, retrieving JNIEnv is very easy if the VM use JNI/1.2:
simply call
- jint GetEnv(JavaVM *vm, void **env, jint version);
and that's it.
you just have to have a global variable to store the vm pointer.
When I deal with native functions and JNI, I define a function that looks
like:
JNIEnv *jni_get_env() {
 extern JavaVM *java_vm;
 JNIEnv *env;
 int err = GetEnv(java_vm, &env, JNI_VERSION_1_2);
 if(err == JNI_EDETACHED) {
 struct JavaVMAttachArgs args = { JNI_VERSION_1_2 };
 err = AttachCurrentThread(java_vm, &env, &args);
 }
 assert(err == JNI_OK);
 return env;
}
Cedric