Name: vrR10176 Date: 08/15/2003



JNI Spec (http://java.sun.com/docs/books/jni/html/design.html) says:
"11.8.1 No Checking for Programming Errors

The JNI functions do not check for programming errors. Passing illegal
arguments to JNI functions results in undefined behavior. The reason
for this design decision is as follows:

* Forcing JNI functions to check for all possible error conditions degrades
  the performance in all (typically correct) native methods.
* In many cases there is not enough runtime type information to perform
  such checking.
..."

But the JNI spec defines rarely which function argument values are
valid and which are invalid. For example:
  Descriptin of GetFieldID says about clazz argument:
"The clazz reference must not be NULL."
or
  Descriptin of DeleteGlobalRef says about gref argument:
"The gref argument must be a global reference, or NULL."

But most of the function descriptions don't define this. So often
it is not clear from the specification if an argument value is
valid or invalid and how JNI implementation should processes it.

For example let's consider the RI implementation of functions
 Call<Type>Method(JNIEnv *env, jobject obj, jmethodID methodID, ...);
and
 CallNonvirtual<Type>Method(JNIEnv *env, jobject obj, jclass clazz, jmethodID methodID, ...);

Description of both functions says nothing about obj or clazz arguments
set to NULL.
If obj of Call<Type>Method is set to NULL the RI jvm throws NullPointerException.
If obj of CallNonvirtual<Type>Method is set to NULL the RI jvm does not throw
NullPointerException and may crash.
The argument clazz of CallNonvirtual<Type>Method may be set to NULL
or any other value since the hotspot silently ignores this argument.
The class information used by hotspot is actually derived from the
method id.
So this behavior of the functions is not specified and moreover it is
not clear if the NULL value is valid argument or not.

======================================================================