J
John Perks and Sarah Mount
(If there's a good JNI resource somewhere that I haven't found, please
point me there in the first instance.)
Which is the definitive spec? Is it the book "Programmer's Guide and
Specification" (Guide) , or the online doc "Specification" v1.5 (Spec)?
In the Spec, it says that only ExceptionOccurred(), ExceptionDescribe(),
and ExceptionClear() can be called when an exception is pending (end of
Chapter 2). But the Guide (11.8.2) lists several other functions, among
them ExceptionCheck(). It's not simply a question of which is right, but
rather what various JVM vendors have regarded as correct (regarding the
Spec or the Guide as normative) at various points in time. I'm intending
my code to be portable across multiple platorms and vendors, so want to
be aware of the worst-case situation I'd reasonably have to deal with.
(Having been coding according to the Spec, the Guide now implies I could
afford to be a lot less cautious).
One apparently exception-*un*safe function is PopLocalFrame(), which
makes it unique amongst the resource cleanup functions. Is this
accurate? Is there a reason for this?
I think the Guide says that it can lead to undefined behaviour if your
LocalFrame Pushes and Pops don't match on function exit. So does the JVM
only cleanout the topmost LocalFrame on function exit, reasoning that
it's the only one left?
To clarify, what are all the functions that might FatalError() due to
inability to allocate LocalRefs? Is it anything that returns a LocalRef
*except* NewLocalRef (which just returns NULL)? What about
PopLocalFrame() with a non-NULL argument?
Can GetArrayElems() be called multiple times on the same thread for the
same array? I'd imagine that as this has to work in multiple threads,
each primitve array would need to keep track of a pin count (or all of
it buffers copies if it doesn't do pinning), do single-threaded access
would not be a problem. There's certainly no way to tell if an array has
already been Got further up the stack. Would the Get/Release calls have
to nest? I'm just making sure that the Spec's silence on the matter
means I can do what I like as long as I Release them afterwards.
When directly accessing primitive arrays, is it safe to use non-volatile
pointers? Could a delayed write *really* happen after the buffer has
been released (and that memory has possibly been used for something
else)?
With those functions that take JNI Version parameter, will the resulting
JNIEnv only have those function table entries for that version, or the
most recent one? (i.e. is the supplied version a request for a minimum,
or more exact)? If the former, does this mean that the JNI version
hierarchy is guaranteed never to fork, so there is no ambiguity over the
"latest version"? (My library may create a JVM or attach to a thread in
a variety of circumstances, and it may not be possible to know what the
most appropriate version to request is; I'm hoping the JNI just Does The
Right Thing and saves me some trouble). The same holds for the JavaVM
interface.
After a successful call to EnsureLocalCapacity(N) does this mean the
topmost LocalFrame has N LocalRefs *available*, or in *total* (i.e. less
those already allocated)?
For RegisterNatives, the Spec says the functions passed in must
"nominally" have sig
ReturnType (*)(JNIEnv*, jobject objectOrClass,...);
Does this actually mean they should use a va_list and the C calling
convention, rather than JNICALL and explicit params (as in "ordinary"
native methods)?
The jni.h file seems to assume that sizeof(void*)==sizeof(void(*)()),
and that structures are aligned at this size, and also that va_lists can
be copied (which may not be the case, or C99 wouldn't need a va_copy
macro). Are these implicit restrictions (and any others) documented
anywhere? Have they arisen in any practical porting concerns?
What a lot of questions. Thanks in advance.
John
point me there in the first instance.)
Which is the definitive spec? Is it the book "Programmer's Guide and
Specification" (Guide) , or the online doc "Specification" v1.5 (Spec)?
In the Spec, it says that only ExceptionOccurred(), ExceptionDescribe(),
and ExceptionClear() can be called when an exception is pending (end of
Chapter 2). But the Guide (11.8.2) lists several other functions, among
them ExceptionCheck(). It's not simply a question of which is right, but
rather what various JVM vendors have regarded as correct (regarding the
Spec or the Guide as normative) at various points in time. I'm intending
my code to be portable across multiple platorms and vendors, so want to
be aware of the worst-case situation I'd reasonably have to deal with.
(Having been coding according to the Spec, the Guide now implies I could
afford to be a lot less cautious).
One apparently exception-*un*safe function is PopLocalFrame(), which
makes it unique amongst the resource cleanup functions. Is this
accurate? Is there a reason for this?
I think the Guide says that it can lead to undefined behaviour if your
LocalFrame Pushes and Pops don't match on function exit. So does the JVM
only cleanout the topmost LocalFrame on function exit, reasoning that
it's the only one left?
To clarify, what are all the functions that might FatalError() due to
inability to allocate LocalRefs? Is it anything that returns a LocalRef
*except* NewLocalRef (which just returns NULL)? What about
PopLocalFrame() with a non-NULL argument?
Can GetArrayElems() be called multiple times on the same thread for the
same array? I'd imagine that as this has to work in multiple threads,
each primitve array would need to keep track of a pin count (or all of
it buffers copies if it doesn't do pinning), do single-threaded access
would not be a problem. There's certainly no way to tell if an array has
already been Got further up the stack. Would the Get/Release calls have
to nest? I'm just making sure that the Spec's silence on the matter
means I can do what I like as long as I Release them afterwards.
When directly accessing primitive arrays, is it safe to use non-volatile
pointers? Could a delayed write *really* happen after the buffer has
been released (and that memory has possibly been used for something
else)?
With those functions that take JNI Version parameter, will the resulting
JNIEnv only have those function table entries for that version, or the
most recent one? (i.e. is the supplied version a request for a minimum,
or more exact)? If the former, does this mean that the JNI version
hierarchy is guaranteed never to fork, so there is no ambiguity over the
"latest version"? (My library may create a JVM or attach to a thread in
a variety of circumstances, and it may not be possible to know what the
most appropriate version to request is; I'm hoping the JNI just Does The
Right Thing and saves me some trouble). The same holds for the JavaVM
interface.
After a successful call to EnsureLocalCapacity(N) does this mean the
topmost LocalFrame has N LocalRefs *available*, or in *total* (i.e. less
those already allocated)?
For RegisterNatives, the Spec says the functions passed in must
"nominally" have sig
ReturnType (*)(JNIEnv*, jobject objectOrClass,...);
Does this actually mean they should use a va_list and the C calling
convention, rather than JNICALL and explicit params (as in "ordinary"
native methods)?
The jni.h file seems to assume that sizeof(void*)==sizeof(void(*)()),
and that structures are aligned at this size, and also that va_lists can
be copied (which may not be the case, or C99 wouldn't need a va_copy
macro). Are these implicit restrictions (and any others) documented
anywhere? Have they arisen in any practical porting concerns?
What a lot of questions. Thanks in advance.
John