Re: Distinct ID Number Per Object?
Eric Sosman wrote:
The inferential error, if there was one, was mine: When
you wrote about the "Identity" of an Object, I assumed you
meant its System.identityHashCode() value. My assumption was
Oh, I see. No, I'd've said the method name in full if I meant it.
There is nothing in the System.identityHashCode() Javadocs to suggest that it
returns unique values even in a 32-bit JVM. I was referring to the rather
complex and unspecified actual JVM "address", to which I refer always in
quotes because it is not an address as thought of in many other machine
architectures.
(I thought) strengthened when you described the "Identity" as
"the internal `address'" of the object, which matches the
Yes, but not the System.identityHashCode().
highly suggestive (but not 100% prescriptive) Javadoc. Did
I don't think it's "highly" suggestive at all. They say they implement the
Object.hashCode() method as a conversion to int from the "internal address" of
an object. They clearly do not specify that conversion, nor what they mean by
the "internal address". A cursory examination of how such "internal
addresses" are implemented reveals, for example, that Sun's implementation is
a pointer to a table of a pair of pointers to locations in the class area and
the heap. Clearly this is "converted" to int via an algorithm that, as has
been documented and restated, reduces the value set from the domain ("internal
addresses") to the range (int). There is nothing in the Sun document from
which one can conclude that this conversion results in a unique value; /au
contraire/ the documents for hashCode(), and transitively
System.identityHashCode(), explicitly warn that the value cannot be guaranteed
to be unique. Again, 32-bit or 64-bit makes no difference.
you have some other way to find "the internal `address'" of a
Java object?
No, nor was this a topic in this thread. There was a misstatement upthread
that the "internal address" is somehow equivalent to the hashCode(), but that
is neither my nor Sun's fault.
I find it generally irrelevant to look for this "address". It is enough to
hold a reference in a variable.
System.hashCode() is the closest thing I canthink of, but there are many things I haven't thought of ...
I assume you mean Object.hashCode(), which System.identityHashCode() invokes.
There is nothing in the return value of either method that is structurally or
meaningfully similar to the address of the object. These methods return an
int; a JVM "address" is certainly not an int, nor conceptually representable
as a one-to-one mapping to the int range. Nor is the "address" required to
remain "constant" during the lifetime of the object, unlike the return value
of hashCode(). The two are in completely different semantic spaces.
And yes, the point of my question was that a 64-bit JVM
can (given enough heap) create more distinct objects than
there are hashCode() or identityHashCode() values. I was
So does a 32-bit JVM, potentially. Neither method guarantees a unique result,
within the JVM, within an application, or within a moment. That is why both
HashMap and IdentityHashMap have to resolve collisions. Even in a 32-bit
environment.
However, the object's "address", whatever that is, is perforce unique.