3

why java Object class has two methods hashcode() and equals()? One of them looks redundant and its percolated to the bottom most derived class?

Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140
Neeraj
  • 293
  • 2
  • 10
  • 5
    You could at least try reading the API -- the Javadoc for Object.hashcode() explicitly says "This method is supported for the benefit of hashtables such as those provided by java.util.Hashtable." – William Billingsley Mar 18 '10 at 11:14

4 Answers4

12

Why do you think one is redundant? They say different things:

  • hashCode is "give me some way of efficiently seeing whether two objects are likely to be equal"
  • equals is "check whether this object is genuinely equal to another"

You definitely need both - although I don't believe they should really be in Object in the first place.

You absolutely need hash codes in order to perform efficient lookups with hash tables - and you absolutely need further equality checks because hashes will collide (there are far more possible strings than hash codes, for example).

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 1
    "I don't believe they should really be in Object." Do you mean both of them, or just hashCode()? equals() as a final method to check identity (probably named differently to avoid confusion) would seem in the right place to me. equals() as a virtual method to check equality does seem to be in the wrong place, though. – R. Martinho Fernandes Mar 18 '10 at 11:16
  • 2
    @Martinho: Both. Reference identity can be checked with == already... but most types don't really have the concept of "equality" or a sensible hash based on their data - so why advertise them for all objects? The blog post has more details, of course :) – Jon Skeet Mar 18 '10 at 11:20
2

First of all, when you override equals() you MUST override hashcode() as well.

Failure to do so will result in a violation of the general contract for Object.hashCode, which will prevent your class from functioning properly in conjunction with all hash-based collections, including HashMap, HashSet, and Hashtable.

Here is the contract, copied from the Object specification [JavaSE6]:

  • Whenever it is invoked on the same object more than once during an execu- tion of an application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execu- tion of an application to another execution of the same application.
  • If two objects are equal according to the equals(Object) method, then call- ing the hashCode method on each of the two objects must produce the same integer result.
  • It is not required that if two objects are unequal according to the equals(Object) method, then calling the hashCode 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 hash tables.
Sorantis
  • 14,496
  • 5
  • 31
  • 37
2

The fundamental idea is that by comparing hashcode()s it's quick to check whether two objects are probably equal. If their hashcodes are equal, then the objects probably are equal (not necessarily, but it's a good guess). Then a more profound (and more expensive) check with equals() is performed. This is important to speed up all kind of look-ups (from maps etc).

Joonas Pulakka
  • 36,252
  • 29
  • 106
  • 169
1

equals is to compare objects, hashcode is used to generate a hash value from an object, which will then be used by the java map containers (Hashtable, Map etc).

it's common practice to override them together (if you override hashcode, you need to override equals and vice versa).

Omry Yadan
  • 31,280
  • 18
  • 64
  • 87
  • 2
    @Neeraj: hashCode can have collisions, i.e., objects with the same hashCode, aren't always the same. – R. Martinho Fernandes Mar 18 '10 at 11:12
  • There it is not for. Two entirely different objects can have the same hashcode. Imagine, the hashcode has a max value of `Integer.MAX_VALUE`, while you can in theory create an infinite amount of distinct objects. – BalusC Mar 18 '10 at 11:13