Re: GTK peer switching JNIEnv *?

[Mark Wielaard]

Hi,

On Fri, 2005-01-14 at 13:49 +0000, Robert Lougher wrote:
> Making
> it static means there's only ever one JNIEnv*, which is fine for JamVM
> as it's got no thread-specific stuff in it.

This is the same model as used by libgcj. But kissme for example has
different structures for each thread. (And indeed has trouble with our
gtk+ peer model at the moment.)

> The spec just says that
> the "VM is guaranteed to pass the same interface pointer to a native
> method when it makes multiple calls to the native method from the same
> Java thread".  It would be an interesting question to ask if JNI code
> should expect the JNIEnv* to be different for different threads. 
> Opinions?

The JNI book (8.1.1) says: "The Java virtual machine passes a native
method the same JNIEnv pointer in consecutive invocations from the same
thread, but passes different JNIEnv pointers when invoking that native
method from different threads." and (11.5.1) says: "Native code may use
the JNIEnv pointer as a thread ID that remains unique for the lifetime
of the thread."

Although I admit never having seen code actually use the JNIEnv pointer
as a unique thread ID. I do interpret this as saying that it could do
that and that the runtime must guarantee that each (java-level) thread
should have its own unique JNIEnv associated with it.

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part