--On Tuesday, July 04, 2000 1:37 AM +0100 Miles Sabin
<[EMAIL PROTECTED]> wrote:
> Mo DeJong wrote,
>> There seems to be a really serious bug in the
>> System.identityHashCode() method in all > JDK 1.2 releases
>> derived from Sun code. The problem only shows up in "high
>> load" situations. Basically, two different Java objects of
>> the same class can return the exact same unique id from the
>> System.identityHashCode() method.
> Why is this a bug? The only requirement on a hashCode (system
> or otherwise) is that two == or .equal() objects should have
> the same hashCode. There's no requirement that != or !.equal()
> objects should have different hashCodes.
While this is true of generic implementations of hashCode(),
Object.hashCode() does have this additional constraint from the spec:
"As much as is reasonably practical, the hashCode method defined by class
Object does return distinct integers for distinct objects."
For most practical implementations of VM's this means they just return the
pointer value, so on systems with less than 2^32 bytes of virtual memory,
you can usually get away with the assumption that if (a != b)
System.identityHashCode(a) != System.identityHashCode(b).
> You shouldn't expect System.identityHashCode() to be usable as
> a UID. Assuming otherwise is non-portable ... as you've just
> discovered.
This I agree with completely. If you really must implement your own.
System.identityHashCode() can be used, with limitations, to implement an
identity hash table, but you have to be VERY careful and aware of the
potential problems involved. In general, using the standard hashCode()
methods to implement hash tables in the like is dangerous business.
I do think it's unfortunate that the java.lang.* hierarchy doesn't have
something which provides a guarunteed unique identifier for an object in
memory.
--Chris
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
