equals() and hash() can be customized: sure, but they serve to establish the identity; nothing more and nothing less. For all we know, Java could have asked us to override a method called 'identify()', instead of the pair of equals/hash, to help establish the identity. As for the need to override, the most obvious is what you refer to: customization. As a creator of the class I get to decide what determines the identity of the object. In your project, an Employee object's identity may be based on EmployeeID member variable; In my project, the same may be ascertained by the first two characters of an UTF8-based EmployeeID.

The point I am making is that for objects that only carry the data from one point to the other, making the members 'public final' are sufficient to establish the uniqueness of the object. One doesn't need the ceremony of setters/equals/hash etc. Such data-carriers have no behaviour; in other words, they don't have any operations that their types permit. Javabeans were the earliest incarnations of such data-carriers. We are carrying on the traditions.

At many places in the projects I am involved in, I am passing Tuples (instead of heavy data-carriers). As long as the postional semantics of the Tuples are easily manageable, this arrangement serves the purpose more than obviously.

In DDD (I am quite a fan of DDD), they are assigning meaning to the terms like DTO / DAO etc. I am trying to simplify it: there are classes that represent a non-trivial Type with Operations ('BankAccount', 'FMRadio', 'WirelessMouse' etc.) and there are classes that represent just a set of named values being passed around ('UserFormInput', 'RecordsReadFromFile', 'JDBCRow' etc.). The second category doesn't need any ceremony! :-)