Eric Sosman wrote:
Lew wrote:
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. [...]
Can you find this guarantee in the Javadoc or other
authoritative place? Does this rule out 64-bit JVM's?
You mean the guarantee that an object's "address" is unique during its
lifetime? How else would the JVM find a particular instance? In
other words, how could it possibly not be?
If two objects had the same "address", then a reference using that
"address" would not reference a single object, which contradicts the
very definition of an object reference.
<http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.5>
a reference to the newly created object is returned as the result
[of] the indicated constructor
There is no way for one "address" to point to two objects simultaneously.
This question has nothing to do with bit width, AFAICS. I'm not
really sure how there could even be a question here.
JVM. Therefore System.identityHashCode(Object) cannot, in a 64-bit VM