10

My co-worker was overriding the equals() method. My response was, have you also overridden the hashCode() method? His response was because we won't use hash map or hash set, it shouldn't really matter if we override hashCode(). Is that correct?

Ravindra Gullapalli
  • 9,049
  • 3
  • 48
  • 70
user1739658
  • 253
  • 1
  • 3
  • 10

6 Answers6

14

Yes he is factually right - however, if you need to put your objects in a hash-based collection one day, you will have to add hashcodes everywhere, which can be annoying + on that day you might implement your hashcode incorrectly (i.e. not consistent with equals) because you miss some subtlety in the equals method...

Considering that most IDEs provide an auto equals/hashcode generation feature, I see little reason not to create both.

Another way to look at it is: when you override a method from a parent class, you should follow the contract defined by that parent class. In the case of Object, the javadoc of equals is pretty clear:

Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.

So unless you have a real design reason not to override hashcode, the default decision should be to follow the parent class contract and override neither or both.

assylias
  • 321,522
  • 82
  • 660
  • 783
  • 2
    +1 But on the other hand, if `equals` is what the code depends on now, there's a very high chance of `hashCode` falling behind the changes to `equals`, once again ending up inconsistent with it. The best compromise, to my eyes, would be a simple `return 1;`---at least it's technically correct. – Marko Topolnik Feb 08 '13 at 21:00
  • 7
    My issue with `return 1;` is that it seems likely to lead to silent, difficult-to-debug performance problems if you use `HashSet` later. Instead, I'd implement `hashCode()` as `throw new UnsupportedOperationException()`, which requires minimal effort, but makes it obvious when you come back and use a `HashSet` later that you didn't bother implementing `hashCode()` the first time. – Louis Wasserman Feb 08 '13 at 21:19
  • 1
    @LouisWasserman Throwing an exception if you *really* don't want to implement hashcode is a very good idea indeed. – assylias Feb 08 '13 at 21:29
  • Thank you very much everyone! assylias - what do you mean by "you will have to add hashcodes everywhere" in the first paragraph? Doesn't my co-worker just need to add the `hashCode()` method back to that one class which he overrides `equals()`? – user1739658 Feb 08 '13 at 23:19
  • If only one class is involved then yes you only have one method to add - I thought he wanted to apply it to many classes. – assylias Feb 08 '13 at 23:58
  • @Marko, return 1 is probably the worse idea - if will work properly except turning the hashmap into a linkedlist (as of now, no standard map in java is open address). – bestsss Feb 10 '13 at 10:25
  • People should be very aware what they use as keys in hashtables, generated hashcode/equals do suck usually (performance wise - no, statistical fast exit, etc, etc), hence I never use 'em. – bestsss Feb 10 '13 at 10:26
  • @bestsss Yes, I'm quite aware of the consequences. It is a vast improvement over an *incorrect* `hashCode`, though. BTW what **do** you use instead of provided `hashCode`? There's not really much choice if you are hashing an object based on encapsulation. – Marko Topolnik Feb 10 '13 at 10:40
  • @Marko, I meant I do not use the auto-generated `hashCode` and `equals` by IDEs. The IDE simply doesn't know how to efficiently generate them. My point is: if one wants to use a class as a key it must be designed like such, incl. being immutable. Being mutable doesn't affect putting an object into a list but totally wrecks it being contained into map (set). I'd rather have wrong hashCode, so it's caught immediately than a technically correct one that has the ability to destroy the performance once it makes it to production. – bestsss Feb 10 '13 at 14:05
  • @bestsss I see your point now. Yes, changing a key while committed to a hashmap is a disaster because it is difficult to track down. – Marko Topolnik Feb 10 '13 at 14:12
5

If you override equals(), do override hashCode() as well. Even if you don't use hashCode() now, you or somebody else might use it.

For more on this topic, check the excellent SO answer

Community
  • 1
  • 1
harpun
  • 4,022
  • 1
  • 36
  • 40
4

It's a code smell. Findbugs for example will warn you if you override either hashCode or equals without overriding the other. You should override both so that they are consistent with one another (that is, a.equals(b) => a.hashCode() == b.hashCode()).

A little effort now may save a lot of headaches later.

sjr
  • 9,769
  • 1
  • 25
  • 36
  • or.. having hashCode on a class not designed to be a key (being mutable for instance) can cause you a lot of more trouble later. Not having overridden hashCode will be caught immediately, having broken hashCode is much harder to trace. – bestsss Feb 10 '13 at 14:23
  • if it's not supposed to be a key in a hash structure you can throw an exception inside hashcode... there is precedent for that for example in Google protocol buffers when the protocol message contains a MessageSet – sjr Feb 11 '13 at 18:38
  • While a good solution if has the potent to break existing code (overall no one expects `hashCode()` to throw an exception). I know code that uses hashCode to test for null (i.e. expecting NPE) [bogus getClass() would have been better] - so again it might be ok - but proposing it default is a bit risky. – bestsss Feb 11 '13 at 20:12
1

You must override hashCode in every class that overrides equals. 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.

Effective Java Item 9: Always override hashCode when you override equals.

If your class is a public class then you can not control how your classes will be used in future development. Without looking into source code (or through reflection) there is no way to know whether this class has overriden the hasCode method or not and the user will be surprised by the result if they use it in any hash based collections.

assylias
  • 321,522
  • 82
  • 660
  • 783
Santosh Kumar Pandey
  • 91
  • 3
  • That's true! I think my co-worker probably didn't think about releasing his code for other people to use and that he is probably going to be the main person working on the framework. – user1739658 Feb 08 '13 at 23:45
0

General:

only override those methods which you want to use in your own way and also those methods which are affected by this overriding.

Specific to your Ques:

From java docs,

Note that it is generally necessary to override the hashCode method whenever equals() method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.

Equals

Arpit
  • 12,767
  • 3
  • 27
  • 40
  • That is generally true, but equals and hashcode are really meant to be consistent: overriding none or both is the default choice, making them inconsistent (overriding only one of them) is an important design decision. – assylias Feb 08 '13 at 20:41
  • i think now i make some sense in my ans. – Arpit Feb 08 '13 at 20:43
0

Actually assume that you create two different objects without overriding equals and hashCode methods. And then if you call equals method java calls hashCode method implicitly then checks the equality of hashcodes.

Overriding hashCode method is enough for checking equality of two objects. And it will be useful for future. You can use this class on collections.

Otherwise if you implement just equal method, it will solve just equality of two objects not more.

emin
  • 742
  • 9
  • 21
  • Java doesn't implicitly call `hashCode` for the default implementation of `equals`. It verifies two objects point to the same reference using `==`. You can have `hashCode` return a random value on every call and the default implementation of `equals` will still work if you point to the same object. – Marc Baumbach Feb 08 '13 at 20:52
  • Your statement about checking equality by hashCode() is actually incorrect. Same hash code doesn't guarantee you equality. – ATrubka Feb 08 '13 at 20:53
  • Yes Mark you are right it checks references. ATrubka,in my answer I especially specified that default implementation of Object class will be used for my example. The other possibilities not specified in my answer. – emin Feb 08 '13 at 21:02