The theory (for the language lawyers and the mathematically inclined):
equals() (javadoc) must define an equality relation (it must be reflexive, symmetric, and transitive). In addition, it must be consistent (if the objects are not modified, then it must keep returning the same value). Furthermore, o.equals(null) must always return false.
hashCode() (javadoc) must also be consistent (if the object is not modified in terms of equals(), it must keep returning the same value).
The relation between the two methods is:
Whenever a.equals(b), then a.hashCode() must be same as b.hashCode().
If you override one, then you should override the other.
Use the same set of fields that you use to compute equals() to compute hashCode().
There are some issues worth noticing if you're dealing with classes that are persisted using an Object-Relationship Mapper (ORM) like Hibernate. If you didn't think this was unreasonably complicated already!
Lazy loaded objects are subclasses
If your objects are persisted using an ORM, in many cases you will be dealing with dynamic proxies to avoid loading object too early from the data store. These proxies are implemented as subclasses of your own class. This means thatthis.getClass() == o.getClass() will return false. For example:
Person saved =newPerson("John Doe");Long key = dao.save(saved);
dao.flush();Person retrieved = dao.retrieve(key);
saved.getClass().equals(retrieved.getClass());// Will return false if Person is loaded lazy
If you're dealing with an ORM using o instanceof Person is the only thing that will behave correctly.
Lazy loaded objects have null-fields
ORMs usually use the getters to force loading of lazy loaded objects. This means that person.namewill be null if person is lazy loaded, even if person.getName() forces loading and returns "John Doe". In my experience, this crops up more often in hashCode and equals.
If you're dealing with an ORM, make sure to always use getters, and never field references inhashCode and equals.
Saving an object will change it's state
Persistent objects often use a id field to hold the key of the object. This field will be automatically updated when an object is first saved. Don't use an id field in hashCode. But you can use it inequals.
But: You cannot include getId() in hashCode(). If you do, when an object is persisted, it'shashCode changes. If the object is in a HashSet, you'll "never" find it again.
In my Person example, I probably would use getName() for hashCode and getId plusgetName() (just for paranoia) for equals. It's okay if there are some risk of "collisions" forhashCode, but never okay for equals.
hashCode should use the non-changing subset of properties from equals