JPA : not overriding equals() and hashCode() in the entities?

Question

After reading this article , im bending toward not overriding equals() and hashCode() altogether.

In the summary of that article, concerning the no eq/hC at all column, the only consequence is that i couldnt do the comparison operations like :

1. contains() in a List for detached entities, or
2. compare the same entities from different sessions

and expect the correct result.

But im still in doubt and would like to ask your experiences about this whether it is a bad practice to skip equals and hashCode altogether and what other consequences that i still dont know for now.

Just another point of information, im bending towards using List Collections over Set. And my assumption is that i dont really need to override hashCode and equal when storing in a List.

Answer 1

whether it is a bad practice to skip equals and hashCode altogether

Yes. You should always override your equals and hashCode. Period. The reason is that this method is present already in your class, implemented in Object. Turns out that this implementation is generic, and nearly 100% of the times it's a wrong implementation for your own objects. So, by skipping equals/hashCode you are in fact providing a wrong implementation and will (in the best case scenario) confuse whoever uses these classes. It may be your colleagues, or it may be some framework you are using (which can lead to unpredictable and hard-to-debug issues).

There's no reason to not implement these methods. Most IDEs provides a generator for equals/hashCode. You just need to inform the IDE about your business key.

Answer 2

You got the exact opposite conclusion from that article of what it was trying to convey.

Hibernate heavily relies on equals being implemented properly. It will malfunction if you don't.

In fact, almost everything does; including standard java collections.

The default implementation does not work when using persistence. You should always implement both equals and hashcode. There's a simple rule on how to do it, too:

• For entities, use the key of the object.
• For value objects, use the values

Always make sure the values you use in your equals/hashcode are immutable. If you pass these out (like in a getter), preferably pass them out in an immutable form.

This advice will improve your life :)

Answer 3

Read this very nice article on the subject: Don't Let Hibernate Steal Your Identity .

The conclusion of the article goes like this:

Object identity is deceptively hard to implement correctly when objects are persisted to a database. However, the problems stem entirely from allowing objects to exist without an id before they are saved. We can solve these problems by taking the responsibility of assigning object IDs away from object-relational mapping frameworks such as Hibernate. Instead, object IDs can be assigned as soon as the object is instantiated. This makes object identity simple and error-free, and reduces the amount of code needed in the domain model.