hashCode() method

[Vladimir Pavlovic]

Hi!

There is something that I don't understand about hashCode method as it is defined in class Object.

Documentation from SUN says:

"The general contract of hashCode is:
Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer..."

Then it continues:

"As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer..."

What I don't understand is what happens if an object changes its place (address) in memory (for example garbage collector moves it in an other place). Will the hash code for that object still be the same? I know that I can override hashCode method in my class, but what happens with java.lang.Object.hashCode(), i.e. when I don't override? Will it still return the same value as before? If so, how?

Thank in advance to anyone who answers this question.

[Ernest Friedman-Hill]

Hi,

Welcome to JavaRanch!

The hash code for a given java.lang.Object will not change during the life of the object; that would break the contract described in the Javadoc.

Given the situation you describe, I'd assume that the hash code in based on the original address. In the original JVM implementation, object access was via "handles," or pointers-to-pointers. Whereas the object could be moved by the GC, the handle wouldn't; it was the address of the handle that was used as the hash code. I don't know if they do something similar these days or not.

[Joe Ess]

Originally posted by Vladimir Pavlovic:

What I don't understand is what happens if an object changes its place (address) in memory (for example garbage collector moves it in an other place). Will the hash code for that object still be the same?

Unfortunately the method hashCode() is native so we can't see the code, but I imagine that it caches the code in a long-lived variable so that if the memory location changes the code doesn't. java.lang.String's hashCode method is written in Java so it's more transparent. Since Java 1.4 it only calculates the hash once even though it is immutable. So many hash tables use Strings as keys it made sense to keep the hash after it was calculated for performance reasons.