This week's book giveaway is in the Java 8 forum.
We're giving away four copies of Java 8 in Action and have Raoul-Gabriel Urma, Mario Fusco, and Alan Mycroft on-line!
See this thread for details.
The moose likes Java in General and the fly likes hashCode() and System.IdentityHashCode Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "hashCode() and System.IdentityHashCode" Watch "hashCode() and System.IdentityHashCode" New topic
Author

hashCode() and System.IdentityHashCode

Ronnie Phelps
Ranch Hand

Joined: Mar 12, 2001
Posts: 329
1. What's the difference between object.hashCode() and System.identityHashCode(object)? I noticed they return different values for the same object.
2. Why would an object return different values when it's passed to System.identityHashCode(object)
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
The identity hashcode is always the default java.lang.Object implementation, even if the class for a particular object overrides this and computes a different hash code.
The identity hashcode takes no account of the content of the object, just where it is located. The ordinary hashcode may (should) take account of content. Thus, the identity hashcodes for two strings that each contain "hello world" would be different, but the ordinary hashcodes would be the same.
The ordinary hashcode should be coded to be consistent with equals() and compareTo(). The identity hashcode generally isn't consistent with them. In the example above, equals() would return true and compareTo() would return zero, which is consistent with the two strings having the same hash code.


Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Ronnie Phelps
Ranch Hand

Joined: Mar 12, 2001
Posts: 329
Thanks dude that was really helpful!! I understand the difference now. Correct me if I'm wrong but given that the identity hash codes are not equal .. will the == operator allways return false?
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
It is my understanding that, yes, if identity hash codes are different, then == will return false. I think that comparing identity hash codes is the same as comparing object references with ==, although I'm not sure if this is actually required by any spec.
Ronnie Phelps
Ranch Hand

Joined: Mar 12, 2001
Posts: 329
Thanks man. I appreciate it.
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Peter Chase:
It is my understanding that, yes, if identity hash codes are different, then == will return false. I think that comparing identity hash codes is the same as comparing object references with ==, although I'm not sure if this is actually required by any spec.
It's not required: if two identity hash codes are equal, then == does not necessarily return true (as you'd expect with hash codes in general, actually). But... I suspect this will only happen on 64-bit JVMs with a memory pool over 4GB in size
- Peter
Ronnie Phelps
Ranch Hand

Joined: Mar 12, 2001
Posts: 329
Originally posted by Peter den Haan:
Originally posted by Peter Chase:
[b]It is my understanding that, yes, if identity hash codes are different, then == will return false. I think that comparing identity hash codes is the same as comparing object references with ==, although I'm not sure if this is actually required by any spec.
It's not required: if two identity hash codes are equal, then == does not necessarily return true (as you'd expect with hash codes in general, actually). But... I suspect this will only happen on 64-bit JVMs with a memory pool over 4GB in size
- Peter[/B]


HUH?
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
Yes, I now realise that it cannot be required that equal identity hashcode implies equal object location. Identity hashcode is an int, hence 32 bits. On some machines, location is a 64-bit value, so the identity hashcode cannot represent all possible locations.
So, for future-proofing, I guess we should never assume that comparing identity hashcodes is sufficient to determine whether two object references refer to the same object.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: hashCode() and System.IdentityHashCode
 
Similar Threads
How to System.out.println the string reference
A question about String.
== operator....
Question about clone a Hashtable
Difference between String s = "Marcus"; vs String s2 = new String("Marcus");