3

Possible Duplicate:
what is an objects hashcode
How do hashCode() and identityHashCode() work at the back end?

I'm not talking about String class or any other class where the hashcode is overridden. Say if I just create a new object of the Object class, then will the hashcode() or to be true in any case, identityHashCode(Object x) return the memory address of that object?

Community
  • 1
  • 1
samsamara
  • 4,630
  • 7
  • 36
  • 66
  • I'm pretty sure that it doesn't on OpenJDK, or we would see much more patterns in the `identityHashCode()` of consecutively created objects. (Try it, create 100 objects, print their hash code and try to find a pattern). – Joachim Sauer Jun 06 '12 at 16:01
  • Last I looked, the default implementation, if the specific class didn't override it, was to return an integer derived from the address of the object at the time the hash code was first requested. Of course, for a copying GC the address may change, so the implementation (if it uses the address) must be careful to cache the hash code first produced and always return that, vs re-deriving it. There is no *requirement* that the hash code have any relation to the address, and for some objects (eg, Strings) it will most definitely NOT be based on address, since equal objects must have equal hashes. – Hot Licks Jun 06 '12 at 16:18
  • here is a link on **how**: http://stackoverflow.com/questions/4930781/how-do-hashcode-and-identityhashcode-work-at-the-back-end – bestsss Jun 06 '12 at 16:19
  • @HotLicks, someone really has to fix the non-sense doc, it's just misleading. – bestsss Jun 06 '12 at 16:27
  • Sometimes the nonsense is intentional. – Hot Licks Jun 06 '12 at 17:26
  • @HotLicks, maybe but not in this case. It was once like that and it has never been updated to reflect reality. – bestsss Jun 07 '12 at 04:59

4 Answers4

7

Not necessarily. From the documentation (emphasis mine):

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, but this implementation technique is not required by the JavaTM programming language.)

NPE
  • 486,780
  • 108
  • 951
  • 1,012
  • 2
    Interesting to note that `hashcode` being an int, it is very possible that the address space on a computer could be larger than the number of available int and that the conversion of the internal address into an int is not necessarily a bijection. – assylias Jun 06 '12 at 16:00
  • "This is typically.." means, are there any other means of implementing it? – samsamara Jun 06 '12 at 16:22
  • @assylias, not necessarily a bijection... but it doesn't matter anyways. – bestsss Jun 06 '12 at 16:25
  • 1
    @user601L, actually it has not been `(jnit) (void*) address` since long long long time, the actual impl. stores a one-time random in the object header. – bestsss Jun 06 '12 at 16:26
  • So but as the doc says, "It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results" is NOT true if the hashcode method hasn't been overridden right? – samsamara Jun 06 '12 at 17:15
  • @user601L -- Read the statement again. It simply says that unequal objects *do not* have to have unequal hashs. ("It is **not** required that...") – Hot Licks Jun 06 '12 at 17:30
  • @HotLicks yes it says that unequal objects don't have to have unequal hashes, i agree with that. But if hashcode() has NOT been overridden, it will return distinct values for distinct objects meaning that unequal objects always have unequal hashes? – samsamara Jun 07 '12 at 03:00
  • @user601L -- That statement is not true. Conceptually (if not actually) you can have more than 4 billion objects, and so the hash could not possibly be distinct. Plus, there is simply no requirement that unequal objects have unequal hashes -- it's not a requirement in any hash implementation on any system I've ever encountered. – Hot Licks Jun 07 '12 at 03:08
  • I see. So when passing objects by reference (as a value) what is used inside is the hashcode of that object (right?), so is it possible to occur collisions in this scenario as well? – samsamara Jun 07 '12 at 06:45
  • @user601L -- The hashcode has nothing to do with passing objects, by reference or otherwise. It is ***not*** an address (even though it's bit pattern may sometimes be identical to the object's address). – Hot Licks Jun 07 '12 at 11:30
  • So then what is that 'value' being passed? – samsamara Jun 07 '12 at 12:13
2

You can always check by looking at the source that ships with your JDK.

My java.lang.Object shows hashCode as a native method. Here are the javadocs.

/**
 * Returns a hash code value for the object. This method is 
 * supported for the benefit of hashtables such as those provided by 
 * <code>java.util.Hashtable</code>. 
 * <p>
 * The general contract of <code>hashCode</code> is: 
 * <ul>
 * <li>Whenever it is invoked on the same object more than once during 
 *     an execution of a Java application, the <tt>hashCode</tt> method 
 *     must consistently return the same integer, provided no information 
 *     used in <tt>equals</tt> comparisons on the object is modified.
 *     This integer need not remain consistent from one execution of an
 *     application to another execution of the same application. 
 * <li>If two objects are equal according to the <tt>equals(Object)</tt>
 *     method, then calling the <code>hashCode</code> method on each of 
 *     the two objects must produce the same integer result. 
 * <li>It is <em>not</em> required that if two objects are unequal 
 *     according to the {@link java.lang.Object#equals(java.lang.Object)} 
 *     method, then calling the <tt>hashCode</tt> method on each of the 
 *     two objects must produce distinct integer results.  However, the 
 *     programmer should be aware that producing distinct integer results 
 *     for unequal objects may improve the performance of hashtables.
 * </ul>
 * <p>
 * As much as is reasonably practical, the hashCode method defined by 
 * class <tt>Object</tt> does return distinct integers for distinct 
 * objects. (This is typically implemented by converting the internal 
 * address of the object into an integer, but this implementation 
 * technique is not required by the 
 * Java<font size="-2"><sup>TM</sup></font> programming language.)
 *
 * @return  a hash code value for this object.
 * @see     java.lang.Object#equals(java.lang.Object)
 * @see     java.util.Hashtable
 */
public native int hashCode();
duffymo
  • 305,152
  • 44
  • 369
  • 561
  • 2
    the impl. of the native is in thread.cpp and synchronizer.cpp :: get_next_hash, http://hg.printk.org/openjdk6-mips/file/tip/hotspot/src/share/vm/runtime/synchronizer.cpp line:270 – bestsss Jun 06 '12 at 16:24
  • Can't imagine why this was voted down three years later. There's value in knowing how to look at the Java source. Where do you think the javadocs come from? – duffymo Apr 11 '15 at 21:25
1

As the documentation on Object.hashCode() states,

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, but this implementation technique is not required by the JavaTM programming language.)

So, the Java language has no requirement for the hashcode of the Object class to return the memory address of the object and therefore you should not rely on this.

konikos
  • 376
  • 2
  • 9
1

No, the HashCode() function returns an integer. If you have not defined a HashCode() function for your object, Java MAY transcode the memory address of the object to an integer and return that.

Chris Dargis
  • 5,891
  • 4
  • 39
  • 63