>>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
Mo> There seems to be a really serious bug in the
Mo> System.identityHashCode() method in all > JDK 1.2 releases
Mo> derived from Sun code. The problem only shows up in "high
Mo> load" situations. Basically, two different Java objects of the
Mo> same class can return the exact same unique id from the
Mo> System.identityHashCode() method. I have a test that
Mo> reproduces this bug every time in > JDK 1.2 JVMs.
It's no bug, the behavior is absolutely legal.
>From the API documentation for java.lang.System:
doc> public static int identityHashCode(Object x)
doc> Returns the same hashcode for the given object as
doc> would be returned by the default method hashCode(),
doc> whether or not the given object's class overrides
doc> hashCode(). The hashcode for the null reference is
doc> zero.
and for java.lang.Object:
doc> public int hashCode()
[...]
doc> The general contract of hashCode is:
[...]
doc> * If two objects are equal according to the
doc> equals(Object) method, then calling the
doc> hashCode method on each of the two objects must
doc> produce the same integer result.
doc> * It is /not/ required that if two objects are
doc> unequal according to the
doc> equals(java.lang.Object) method, then calling
doc> the hashCode method on each of the two objects
doc> must produce distinct integer results.
doc> However, the programmer should be aware that
doc> producing distinct integer results for unequal
doc> objects may improve the performance of
doc> hashtables.
(The latter point is redundant but makes the situation more obvious).
Mo> I have been able to reproduce this error in > JDK 1.2 releases
Mo> from Sun (including blackdown and IBM ports). This also
Mo> happens on all platforms, NT, 95, Linux, and so on. This error
Mo> does not show up with JDK 1.1.8 from blackdown (or any other
Mo> JDK 1.1 JVMs for that matter).
The implementation of Object.hashCode() was changed in 1.2 for
security reasons.
Mo> So far, I have identified a couple of workarounds. I could
Mo> just require that everyone use a JDK 1.1 release. I could
Mo> also require that people use Kaffe (it does not have the
Mo> bug).
It's no bug.
Mo> The final option would be to write my own UID() method that
Mo> would try to do something to detect a duplicate id and
Mo> generate a unique one.
That's the better solution, System.identityHashCode() simply doesn't
guarantee unique values.
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://www.blackdown.org/java-linux.html
JVM'01: http://www.usenix.org/events/jvm01/
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
