On Tue, 4 Jul 2000, Miles Sabin 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.
>
> Apart from anything else, hashCodes are ints, so there are at
> most 2^32 distinct ones. A 64 bit implementation could support
> more that 2^32 objects, in which case there'd have to be some collisions.
>
> > So far, I have identified a couple of workarounds. I could
> > just require that everyone use a JDK 1.1 release. I could
> > also require that people use Kaffe (it does not have the
> > bug). The final option would be to write my own UID() method
> > that would try to do something to detect a duplicate id and
> > generate a unique one.
> >
> > Comments anyone?
>
> You shouldn't expect System.identityHashCode() to be usable as
> a UID. Assuming otherwise is non-portable ... as you've just
> discovered.
I don't get it. That was the whole point of adding the
System.identityHashCode() method to 1.1. It was designed
to return a UID in the case that a class overloaded
the hashCode() method. Now folks seem to be saying "oh,
yeah that was changed for 1.2". Changed to what?
How would you suggest I generate a UID for two
different object of the same class that return
the exact same hash code? I can't get the memory
location to implement my own UID method.
I guess I could create another table of objects
that map to the same hashCode but are not equal.
It might also be possible to map every id to
a Vector instead of directly to the object.
Both of these "solutions" would be really ugly.
I am really getting sick of Sun changing the
APIs in really sneaky ways.
Mo DeJong
Red Hat Inc
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
