SUGGESTED FIX

From a discussion with the bug submitter, I suggest the 
following API.  It will return one of the following
enumerated types.  This api will not distinguish between an object that's
live or one that has recently been deleted.


// Return values from jobjectRefType
typedef enum _jobjectType {
     JNIUnknownRefType    = 0,
     JNILocalRefType      = 1,
     JNIGlobalRefType     = 2,
     JNIWeakGlobalRefType = 3
} jobjectRefType;

JNI_LEAF(jobjectRefType, jni_ObjectReferenceType(JNIEnv *env, jobject obj))
  JNIWrapper("ObjectReferenceType");
  if (JNIHandles::is_local_handle(thread, obj) ||
      JNIHandles::is_frame_handle(thread, obj))
    return JNILocalRefType;
  if (JNIHandles::is_global_handle(obj))
    return JNIGlobalRefType;
  if (JNIHandles::is_weak_global_handle(obj))
    return JNIWeakGlobalRefType;

  return JNIUnknownRefType;
JNI_END
###@###.### 10/6/04 15:42 GMT
                                     

CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
dragon


                                     

EVALUATION

###@###.### 2002-11-13
This is a perfectly good suggestion.  Will try for JDK 1.5 because this
involves a specification change.


###@###.### 2003-02-03
I suggest a new JNI method:

int HandleType(JNIEnv* env, jobject obj);

which examines obj returns

 0:   obj is not a valid reference.
 1:   obj is unknown.  The JVM cannot determine if obj is a valid 
      reference to an object.
 2:   obj is not a valid reference.
 3:   obj is a valid local reference for a thread other than the
      current thread.
 4:   obj is a valid local reference for the current thread.
 5:   obj is a valid strong global reference.
 6:   obj is a valid weak global reference.

----------------------------------------------------------------------------------

I took a look at what it would take to provide a jni service that Fred Oliver
suggested in his evaluation of the bug and I'm concerned about the
performance impact of this call.  

int HandleType(JNIEnv* env, jobject obj);

We maintain at least 3 different linked lists
of JNI Handles for global, local and weak global references.  The overhead
of calling into the VM is bad enough but if you had to call this function
for each handle that you'd like to delete, I'd be concerned with the
performance impact on your applications.

So, I have a few questions for the RFE submitter that might help me design 
a better solution:

If I gave you a new service called DeleteHandle(JNIEnv *env, jojbect);
Which could accept any type of handle, would this be sufficient?

Do you have any idea of the number of handles that you typically create in
your application?  If I doubled the size of the jni handle object and maintained
a type field for each handle, you could have the functionality that you need and
you could check the type of handle without calling into the VM.

I'm not sure how well this type of solution would go over in the Java technical
review committee but it might be worth a try.  A jobject would be a pointer to
a _jobject structure, something like:


struct {
     void *object;
     int handle_type;
} _jobject;

struct _jobject *jobject;

We would then add jni.h macros to determine the type of a handle.

is_local_ref
is_global_reg
is_weak_ref
etc.
###@###.### 10/5/04 17:24 GMT

See suggested fix section for a proposed implementation.
###@###.### 10/6/04 15:42 GMT