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. 

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