Return to Answer

It doesn't. The object's hashcode method is called to do this. See the source code. (line 360).

• The code (in the version I linked to) is hashing Strings using a special method. (It appears that this is to allow hashing of strings to be "tuned" at the platform level. I didn't dig into this ...)

• The hashcode returned by the Object.hashcode() call is "scrambled" further to reduce the chance of collisions. (Read the comment!)

1. If a.equals(a) then a.hashcode() == b.hashcode().
2. While a is in a HashSet or is a key in a HashMap, the value returned by a.hashcode() must not change.
3. if !a.equals(b), then the probability that a.hashcode() == b.hashcode() should be low, especially if a and b are probably hash keys for the application.

Every class inherits a default hashcode() method from Object (unless this is overridden). It uses what is known as an "identity hash code"; i.e. a hash value that is based on the object's identity (its reference). This matches the default implementation of equals(Object) ... which simply uses == to compare references.

The default hashcode() method returns the "identity hashcode". This is typically based on the object's memory address at some point time, but it is NOT the object's memory address.

The bottom line is that the default Object.hashcode() method satisfies all of the requirements that I listed above. It can be relied on.

It doesn't. The object's hashCode method is called to do this. See the source code. (line 360).

• The code (in the version I linked to) is hashing Strings using a special method. (It appears that this is to allow hashing of strings to be "tuned" at the platform level. I didn't dig into this ...)

• The hashcode returned by the Object.hashCode() call is "scrambled" further to reduce the chance of collisions. (Read the comment!)

1. If a.equals(b) then a.hashCode() == b.hashCode().
2. While a is in a HashSet or is a key in a HashMap, the value returned by a.hashCode() must not change.
3. if !a.equals(b), then the probability that a.hashCode() == b.hashCode() should be low, especially if a and b are probably hash keys for the application.

Every class inherits a default hashCode() method from Object (unless this is overridden). It uses what is known as an "identity hash code"; i.e. a hash value that is based on the object's identity (its reference). This matches the default implementation of equals(Object) ... which simply uses == to compare references.

The default hashCode() method returns the "identity hashcode". This is typically based on the object's memory address at some point time, but it is NOT the object's memory address.

The bottom line is that the default Object.hashCode() method satisfies all of the requirements that I listed above. It can be relied on.

^{(How they implement this efficiently is rather clever. See http://stackoverflow.com/a/3796963/139985 for details.)}

^{(How they implement this efficiently is rather clever. See https://stackoverflow.com/a/3796963/139985 for details.)}

^{(How they implement this efficiently is ... a platform specific implementation detail ... but it is rather clever.)}

^{(How they implement this efficiently is rather clever. See http://stackoverflow.com/a/3796963/139985 for details.)}