20

Possible Duplicate:
How is hashCode() calculated in Java

I found there's no implementation in hashCode(） method of root class Object in Java:

public native int hashCode();

If I have an Object a and an Object b, how can I know the a.hashCode() and b.hashCode() value without using System.out.println()? Just by the hashCode implementation.

I have try to new two ArrayList objects and to my big surprise the hashCode() values are the same: both of them are 1.

Community
  • 1
  • 1
andyqee
  • 3,175
  • 3
  • 21
  • 24
  • It is probably a memory address. What are you trying to do? Or are you just curious how it is implemented? – mbelow Nov 28 '12 at 10:08
  • 3
    @nbrooks : it's not duplicate – Nandkumar Tekale Nov 28 '12 at 10:11
  • 1
    It gives you the same value as `System.identityHashCode(x)` which can be useful if the object's hashCode() has been overriden. – Peter Lawrey Nov 28 '12 at 10:13
  • 1
    The accepted answer to the "possible duplicate" doesn't even refer to the Object class - how can it possibly answer this question? People mark way to much stuff as duplicates and it annoys me. Is it possible to unmark this as a duplicate or link it correctly to a duplicate that does answer the same question, such as this one: https://stackoverflow.com/questions/2237720/what-is-an-objects-hash-code-if-hashcode-is-not-overridden – tonicsoft Dec 27 '17 at 12:25

3 Answers3

18

hashCode is a native method which means that a system library is called internally. See Java Native Interface for more details.

There is a question on SO Why hashCode() and getClass() are native methods? Might be interesting for you.

Community
  • 1
  • 1
Kai
  • 38,985
  • 14
  • 88
  • 103
5

The default hashCode is going to be implementation-specific. I suspect it's related to the memory address, but note that the VM moves objects around in memory (and, of course, the hashCode has to remain the same). So it won't be the actual memory address.

Brian Agnew
  • 268,207
  • 37
  • 334
  • 440
3

The default hashcode() implementation frequently but not always provides an integer based loosely on the memory address of the object, however the memory address can change. This may vary based loosely upon the JVM implementation.

hashCode()

As you know this method provides the has code of an object. Basically the default implementation of hashCode() provided by Object is derived by mapping the memory address to an integer value. If look into the source of Object class , you will find the following code for the hashCode.

public native int hashCode();

It indicates that hashCode is the native implementation which provides the memory address to a certain extent. However it is possible to override the hashCode method in your implementation class.

http://www.javaworld.com/community/node/1006

Kevin Bowersox
  • 93,289
  • 19
  • 159
  • 189
  • That's not exact. The memory address can change, the `hashcode` cannot. – John Dvorak Nov 28 '12 at 10:08
  • It's not even correct, and the [Javadoc](http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode()) says so. Your citation is not a normative reference, and the claim it makes hasn't been true since 1997. Whatever 'to a certain extent' is supposed to mean. – user207421 Nov 28 '12 at 10:11
  • @JanDvorak I shouldn't have worded that so concretely. I took your suggestions into account in my answer. – Kevin Bowersox Nov 28 '12 at 10:12
  • 2
    @EJP From the Java Doc `(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.)` I agree its not absolutely derived from memory address, but there seems to be a strong correlation. – Kevin Bowersox Nov 28 '12 at 10:14
  • @kmb385 The operative statement is 'this is not required by the Java programming language'. – user207421 Nov 28 '12 at 10:14
  • @EJP As I said I agree with that, however it must be pretty common practice to include that statement in the API. If it wasn't `frequently` the case why would they even mention it? Not trying to get into a `Who is right war here`, just debating and I respect your POV. – Kevin Bowersox Nov 28 '12 at 10:16
  • 1
    The point is that the Javadoc doesn't specify a required implementation technique, so you can't define one as the answer to this question. It only specifies requirements on the implementation. – user207421 Nov 28 '12 at 10:18