Re: Distinct ID Number Per Object?
Hal Vaughan wrote:
So is it only in extreme cases like this where hashcodes would be
duplicated?
Hash codes have even fewer values than Strings. That means there must be
proportionately more collisions. Have you read the Javadocs on the hashCode()
method? You should. Also read the Javadocs on Map, HashMap and IdentityHashMap.
As Twisted pointed out, the "Identity", i.e., the internal "address" of an
object, is unique for the lifetime of that object. Even without
IdentityHashMap, any Map can use an object that doesn't override equals()
(most custom objects, for example) as a unique key into a lookup. It is
sufficient to use a regular Map (e.g., HashMap) when equals() and == define
the same relation. IdentityHashMap is for when they differ and you want the
key selection to be based on ==.
Twisted said:
as the usual implementation of the default hash code for Object is the memory address of that object,
"converted to an integer".
<http://java.sun.com/javase/6/docs/api/java/lang/Object.html#hashCode()>
(This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)
You certainly cannot rely on a correspondence. That is what Sun's
implementation of Object.hashCode() does, but many, many subclasses override
it. It is a best practice (see /Effective Java/ by Josh Bloch) to override
hashCode() in any class that overrides equals(). Since most of the objects in
an application likely are of subtypes of Object, it is common that their
hashCode() will not return the "address" of the object.
Javadocs rule.
--
Lew