1

We known that default implementation of hashCode() returns integer after converting the internal address converting the internal address of the object into an integer . So internal memory of every object is different, then why hashCode() does not generate unique hashcode.

My question is why hashcode() [It returns integer which is address representation of an object] does not generate unique code , if we don't override hashcode() and equals?

Community
  • 1
  • 1
geeks
  • 1,710
  • 7
  • 37
  • 68
  • The default `equals()` doesn't actually check for full equality either. To use either you need to override it; if you don't specify a method what do you expect java to do? – Pokechu22 Nov 04 '14 at 16:26
  • Thanks for your replay But my question is why hashcode does not generate unique code if we don't override hashcode and equals because it is memory representation of an object? – geeks Nov 04 '14 at 16:33

4 Answers4

2

why hashCode() does not generate unique hashcode

Because it has no obligation to do so...

Quoting the javadoc of Object.hashCode():

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.

And indeed, this is a perfectly legal (even though useless) hashCode implementation:

@Override
public int hashCode()
{
    return 42;
}

What is required of the .hashCode() method is that if two objects are equal according to .equals(), then they should have the same result for .hashCode(); and the above method fits the bill!

Mind you, in real life, you would never write such a useless hashCode() method as the above...

Note about the default implementations, that is the ones of Object:

  • Its hashCode() method calls System.identityHashCode();
  • Its equals() method tests reference equality (that is, for objects o1 and o2, it tests that o1 == o2).

If you read the javadoc for Object carefully, you will see that the contract for both methods is obeyed; The implementation for it is as minimal as you can get, but the contract is obeyed.

Unihedron
  • 10,251
  • 13
  • 53
  • 66
fge
  • 110,072
  • 26
  • 223
  • 312
  • You should incorporate this important quote from the doc in to your answer. *"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™ programming language**."* – Radiodef Nov 04 '14 at 16:44
  • @fge Thanks for your replay – geeks Nov 04 '14 at 16:45
  • @neelabhsingh note that you can only accept one answer; be sure to accept the one which answers your question the best! – fge Nov 04 '14 at 16:50
  • @Radiodef not sure whether this is the really important part here... OP seems to be misguided as to what really binds `hashCode()` to begin with; not to mention that there is no guarantee that the hash code for a "same" object will be the same from JVM run to JVM run – fge Nov 04 '14 at 16:53
2

Because it can't.

Since there are only 2^32 different ints and there may be more than 2^32 live objects in any VM instance, it is technically impossible to guarantee a unique hash code for each object.

Even if the default hash code may be based on the internal address of the object, it is not identical to the internal address.

jarnbjo
  • 32,366
  • 6
  • 65
  • 87
  • "Because it can't." That's not quite true; it can do so for enums. It is just that the contract of the method itself does not require it to do so. – fge Nov 04 '14 at 16:33
  • @fge: Why do you think it's possible for enums? – jarnbjo Nov 04 '14 at 16:38
  • @jarnbjo for purely practical reasons; the source of a Java file is limited (I cannot remind the exact limit, but it certainly is less than 2^32 - 1) – fge Nov 04 '14 at 16:50
  • @fge: Yes, there is a limit on the number of different values within one enum type, but the question was not about unique hash codes within one type. And even with one enum type, you can load the type multiple times with different class loaders and obtain more than 2^32 instances of the enum. – jarnbjo Nov 04 '14 at 16:54
  • @jarnbjo no you can't; consider that an enum has a `values()` method! It returns an array, whose max capacity is bound by the `int` primitive type -- its positive values, that it: 2^31 - 1 – fge Nov 04 '14 at 16:59
  • @fge: And why is it an issue that values() returns an array with at most 2^31-1 entries? Your objections are not making sense. – jarnbjo Nov 04 '14 at 17:02
  • @jarnbjo now tell me how a class loader is supposed to handle more than 2^31 - 1 enum values when the `values()` method has to be obeyed? – fge Nov 04 '14 at 17:03
  • 1
    @fge: I wrote that you can load the enum type multiple times with different class loaders. Each class loader will give you different instances of each enum value. – jarnbjo Nov 04 '14 at 17:04
  • @jarnbjo which doesn't dismiss my comment above; it is perfectly possible for an implementation to guarantee a unique hash code for enum values. For instance, the value of `.ordinal()`! – fge Nov 04 '14 at 17:06
  • 1
    @fge: You are obviously incorrectly assuming that an enum value is a singleton, which it is not. If you load the enum type with different class loaders, each value will be its own instance. But I don't know how many times I have to repeat "different class loaders" until you understand that? – jarnbjo Nov 04 '14 at 17:13
  • @jarnbjo similarly, you are obviously misguided in the fact that a same classloader can handle realibly more than 2^31-1 enum values, because of the enum constraint themselves. I wonder how many times I have to repeat that until you understand that? – fge Nov 04 '14 at 17:23
  • @fge: Why are the constraints of one class loader relevant when I all the time talk about several class loaders? And even one class loader is not in any way restricted if it loads multiple enum types with a total of more than 2^32 different values. – jarnbjo Nov 04 '14 at 17:31
  • @jarnbjo obviously you missed the part where an enum is required a consisten `values()` implementation; this method returns an array, and the maximum number of elements in an array is... 2^31 - 1, which is exactly the maximum allowable range for `.hashCode()`. Do you finally understand? – fge Nov 04 '14 at 17:35
  • @fge: No, but it is not me not understanding. Do you understand the concept of class loaders and that multiple class loaders may load the same type more than once? – jarnbjo Nov 04 '14 at 17:53
  • @jarnbjo it will never happen; to user code, when an enum value is asked, there will always be _one_ instance returned, never two. While it is true that the same _class_ may be loaded more than once, spurious instances will be discarded. Now, do you finally understand? – fge Nov 04 '14 at 18:04
  • @fge: No, what you're writing here is simply wrong. If the code runs within different class loaders, the enum values will be represented by different object instances. – jarnbjo Nov 04 '14 at 18:37
  • @jarnbjo nevermind, you seem to have been missing my point from the get go – fge Nov 05 '14 at 00:07
1

hashCode only prints the internal memory adress if it is not overridden! (its using the object implementation)

The hash code for a String object is computed as

 s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]

using int arithmetic, where s[i] is the ith character of the string, n is the length of the string, and ^ indicates exponentiation. (The hash value of the empty string is zero.)

Philipp Sander
  • 9,615
  • 3
  • 41
  • 75
-1

The hash code of an object is not its memory address. If you need to use a unique integer for an instance, there's a special method for that called System.identityHashCode(Object).

The hash code is just an integer (32 bits) that is meant to give a reasonable approximation of equality. If two hash codes are different, the two objects must be different, but if they are the same they may still be different (though usually they are the same).

This means that if you have two different lists with exactly the same content, they will have the same hash code, but a different memory address.

Ghostkeeper
  • 2,543
  • 1
  • 11
  • 22