--On Monday, July 03, 2000 11:58 PM -0700 Mo DeJong <[EMAIL PROTECTED]>
wrote:
> On Mon, 3 Jul 2000, Christopher Smith wrote:
>> > 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.
>> Nope, the whole point of System.identityHashCode() was added so that ==
>> had equivalent operators to Object.equals(Object). Essentially it
>> allowed you to create an identity hash table. If they had ment it to be
>> a uid they would have called it Object.getUid(). ;-)
>
> Humm, I am not sure if we are saying the same thing with different words.
> The System.identityHashCode() is not the equivalent of == in JDK 1.2. In
Nor should it be. Why bother creating a new method for doing something you
can already do with the '==' operator?
> JDK 1.1 it worked that way but now I am not sure what it is the
> equivalent of. It is most certainly not the .equals() method, the
> error example I posted showed that the two objects that mapped
> to the same hash would return false from a equals() comparison.
Perhaps I was not clear enough:
System.identityHashCode() is to "==" as Object.hashCode() is to
Object.equals(Object).
Does that make more sense?
> My example also shows that identityHashCode() is not the equivalent of ==,
> the == test for two objects that hash to the same value returned false.
> What exactly do you mean when you say "identity hash table"? What
> would such a table do for you?
That would give me a hash table where the key is the actual instance of the
object itself rather than some concept of the value of the key. Such that
(forgive the fact that this is 100% syntactically correct, I think it gets
the idea across):
KeyClass keyA = new KeyClass();
KeyClass keyB;
KeyClass keyC;
keyC = keyA.clone(); //assume for KeyClass a.equals(a.clone())
//is always true
keyB = keyA;
identityHash.put(keyC, "testC");
identityHash.put(keyB, "testB");
identityHash.put(keyA, "testA");
System.out.println(identityHash.get(keyA));
System.out.println(identityHash.get(keyB));
System.out.println(identityHash.get(keyC));
Should print out:
testA
testA
testC
>> They didn't change the API. The docs have been the same for quite some
>> time. They did fix a conflict in the spec that said the following:
> Yes they did. The API does not work the same way it did in JDK 1.1.
They changed the behavior, not the API. There is a difference. The
specification is VERY clear that while the VM will make all resonable
efforts to avoid duplicate values of System.identityHashCode(Object), it
makes no guaruntees. One should expect behavior to be different from one
JDK to the next. Indeed, one should be prepared for behavior to be
different from one VM to the next, so long as they're consistent with the
documentation, it's not a change in the API.
>> Standard hashtables are based on Object.equals() and as such deal with
>> the hashCode collision issue. So, if you just use a standard Hashtable
>> (or Set depending on your needs), make sure you're using
>> identityHashCode() and =='s, then collisions will be dealt with for you.
> I am using a "standard hashtable". I need to map a UID string to a
> single Object, without a UID provided by the identityHashCode(),
> I am going to have a hard time doing that.
Actually, it doesn't have to be hard at all. Just create your own UID's. I
do this all the time.
--Chris
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
