Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Doubt regarding the hashCode value

 
Keerthi Kumar
Ranch Hand
Posts: 105
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear all,

In what scenarios, the following code snippet will return same hashcode value

 
Keerthi Kumar
Ranch Hand
Posts: 105
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear all,

Sorry for the wrong entry in the code. Please find the proper code snippet below:

 
Mina Daoud
Ranch Hand
Posts: 88
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hashCode will return the same value if the 2 objects are equals, thus, in the following case it will return the same number:


OR even if you did:



I hope this helps!
 
Keerthi Kumar
Ranch Hand
Posts: 105
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
apart from the same value, is there any other scenarios where it returns the same hashcode value??
 
Mina Daoud
Ranch Hand
Posts: 88
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't believe so, as the hashCode definition is it returns the int representation of an object.If 2 objects are equal based on the method (equals) calling the hashCode() for any of the 2 objects should return the same value.
 
Hauke Ingmar Schmidt
Rancher
Posts: 436
2
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
java.lang.Object#hashCode() returns (should return) the same hashCode for Objects that are equal.

There can be no assumption made what hashCode returns for objects that are not equal.

This...

would be a legitim but not very useful implementation for the method.

As java.lang.String is final you can't change the hashCode implementation. There are different strings that produce the same hashcode, but it is unlikely. (Even passwords are typically stored only as hashes and compared based on hashs - which would be a quite bad idea with the hashcode implementation from above ^^.)
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24204
34
Chrome Eclipse IDE Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ummm.... no.

Let's consider just the upper and lower-case Latin alphabet, which is a total of 52 letters. How many different 8-character strings could we make? We can choose any letter for the first, and any letter for the second, etc. Altogether there are 52^8 different strings of 8 Latin letters. That's 53459728531456 different Strings, which is far more than the 4294967295 different values the int that hashCode() returns can hold. This means that even for such short Strings, there are an enormous number of pairs of Strings that have the same hashCode()!

The chances that any two Strings will have the same hashCode() values is quite small. The chances that, out of a collection of Strings, two of them will have the same hashCode() are rather large! This surprising statistical result is often called the Birthday_paradox. Did you know if you get 23 people in a room, the chances are 50-50 that two people among them share the same birthday?
 
Hauke Ingmar Schmidt
Rancher
Posts: 436
2
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are right.

Ernest Friedman-Hill wrote:The chances that any two Strings will have the same hashCode() values is quite small.


That is what I had in mind.
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic