How long lasts the unicity (if any) of the System.identityHashCode()?

Question

How long lasts the unicity (if any) of the System.identityHashCode()?
I created code that keep track of seen identityhashcodes for instances
created and unreferenced in a loop.
**** I was surprised to see that these identityhashcode can be reused! ****
The language spec says noting about the unicity of those (at any given time) and especially not for periods of tiem.
Spec menyions that most jvm would use the heap address (which would explain why these identityhashcode could be reused)
**** The question is:
At what time is an identityhashcode invalidated and reusable?
If I have a finalize() method, at which time the object is considered unreferenced, could its identityhashcode be reused while the finalize() is running?
My problem is that I associated data to an object, in an external diskcache, by a key whose value is the identityhashcode, (trying to make the key unique), and I must garbage collect it.

Answer 1

Casually? yeah right, 64bit platforms are just a minor
detail.... ;-)
I wasn't clear about my hopes. I just hoped that for
reflecting new architectures, they would had a new
method
like System.getUniqueObjectID(Object):long
Basically, if sun does not add that, it means that
they beleive the java programmers do not have a need
for addressing/keying object instances uniquely, and
we should just do for-loops with "=="....
I will post an RFE to sun, we'll see.
Thanks.It is not required that hashCode every return a value larger then an int. There is no requirement that
two different objects return two different hashCodes. There is only the requirement that if two objects are
the same then they return the same hashcode. Most 32 bit JVM's do not produce a unique hashCode value
for all objects. Because of this there is also no need for 64 bit JVM's to return unique hashcodes. Hence
64 bit JVM's do not need more then an int to represent the hashCode.
The equals() method (or ==) is used to determine whether two objects are equal. Not the hashCode.
Increasing the size of hashCode to a long would break a large number of classes in the JDK all of which
expect an int. HashMap/hashTable/HashSet are the prime users of hashCode. They do not require a value
larger then int as they use the value to index into an array. Arrays cannot be larger then 2^31 elements
long. This also will not change on 64 bit JVM's as changing this limitation would break most of the API's.
matfud