Name: jl125535 Date: 02/06/2004


A DESCRIPTION OF THE REQUEST :
provide a strict System.uniqueObjectID(Object)
similar to identityhashcode, that would return a long
that "really" uniquely identifies an object instance in the heap.

System.identityhashCode() is not guarantying uniqueness, and does not
mention the timeline of the validity of this identityhashcode.

instead of changing the current System.identityhashCode() api,
add a method for all future versions, that return a long for each living object.

By "living", i mean, when a finalize() method is ran, this uniqueObjectID is still unique.

As soon as the object is really unaccessible by any code, only then the unique id value could be reused (this is mostly related to jvm usually taking the memory address, which will be a problem on 64bits address space)


JUSTIFICATION :
there is no garanteed unique instance "key" available.

mostly related to jvm usually taking the memory address, which will be a problem on 64bits address space

The "identity" is defined as the ultimate equality of to entities (objects). The current identityHashCode do not provide this facility as expected. It provides an hashcode, but not an "identity" one.

For every existing object in the jvm, there should be the ultimately unique key to it, one primitive type (technically, a long on future 64 bits platforms) that would allow to track flawlessly an object, and especially associated data to it, on other system that can't handle a java object (no rmi UID or the like either).

For example: it is easy in java to use an IdentityHashMap whose values are pointers to a file index block on a randomaccessfile, for swapping data, for instance. IdentityHashMap is supposed to used object reference equality "==" if 2 identityHashCode are the same.

Imagine that swappable cache is on a remote system. It does not have those object references and worse, cannot do == tests atomically (object may moved, be gc'ed, etc...)

If you were to ask a hypotetical out-of-jvm RemoteIdentityHashMap get(Object), you would have to send something to the remote entity, and that should be the ultimate unique key of your object. The only other way is to request a peer "unique key" on the remote entity before processing.

That would be like asking an IdentityHashMap to give you an hashcode so that you can store it in your "HashCodeAble" object so that it can be queried later by the map implementation.

Given that all objects have a facility hashCode method for "possible" mapping tasks, I think it is even more mandatory that all objects have a unique key for "more-than-possible" identity checks.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
provide a strict System.uniqueObjectID(Object)
similar to identityhashcode, that would return a long
that "really" uniquely identifies an object instance in the heap.
ACTUAL -
System.identityhashCode() is not guarantying uniqueness, and does not
mention the timeline of the validity of this identityhashcode.

and "int" is not sufficient for 64 bits platforms
(Incident Review ID: 236873)
======================================================================