For adding an object in set, is it necessary to override equals and hashcode both.?

Question

Recently an interviewer asked me that I have a class where I have overriden its equals() method but have not overridden my hashCode() method.

Now is it necessary to override my hashCode() method too.?

What will happen if i don't override my hashcode method, will set maintain its unique property of not allowing duplicates.?

The question is all about internal implementation of Set and here my confusion is if two objects return different hashCode(), according to me their equals() won't be checked and then the unique property of Set will be violated if the two objects came out to be equal.

Is that true.?

Answer 1

It really depends on the concrete Set-implementation, as mentioned by the Collection doc (Collection is the super-class of Set)

(The Object.hashCode() specification guarantees that two objects with unequal hash codes cannot be equal.) More generally, implementations of the various Collections Framework interfaces are free to take advantage of the specified behavior of underlying Object methods wherever the implementor deems it appropriate.

So, for instance the HashSet (as the name suggests) will use the hash value, other implementations of Set may not - and only ever use equals()

finally some good advise from the Object.equals doc:

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.

Answer 2

You should always override both. They are part of a contract.

Look at the java docs and make sure you fulfil the details there. Eclipse can also generate these methods for you.

Answer 3

The easiest way to understand this is to see hashcodes as buckets.When you store objects in sets they go to these buckets according to their calculated hashcode.

When you override equals , that is one object is equal to another, so they should land in the same bucket.

However that won't be the case since you haven't overriden the hashcode method to ensure this.

So jvm will try to search the object in the wrong bucket. won't find it and as a result you'll have duplicates. (btw my interviews are starting soon as well , really scared!)

Answer 4

Both are always recommended.

E.g. If you have super Class Person with properties id,, name, surname and you define equals and hashCode based on name and surname and a concrete sub Class Contact Person with extra properties like email, it's important to define new equals and hashCode for your Class Contact Person. If your Concrete Class Contact Person implements an entity having the email property as a unique field, redefining equals and hashCode based only on email would be enough. Though, defining a new equals and hashCode based on name, surname, and email is better.