There is well known problem with implementing equals() (and hashCode(), i will speak about equals() only) for persistance object with database managed id.
New object is not stored in database, therefore does not have database identity, therefore its “id” field is null (or 0 if it is primitive type).
If equals look at id, it will consider all new objects equal, and once it gets id, hash code change so if it already was in hash sensitive collection, it will not be found.
One solution is using business key, but sometimes everything except surrogate id is mutable.
Another solution is to generate (one more, or use it as databes id too) surrogate id when object is created.
Approach I haven’t seen mentioned is, use id in equals and make equals (and hashCode()) fail (throw IllegalStateException) when id is null. (and document this behavior)
This way it still can’t be in hash collections, but it cannot be accidentaly put there. And for puting it in collections when without id, some wrapper can be used.
Is it good/bad idea? Does it have hiddent problems?
As kan pointed out, if child objects should be put in Set property and persisted with their parent, inability to put objects in Set before they are persisted is big problem (and TreeSet does not help, because it uses equals(), even if it does not use hashCode()).
I mostly use list for child entities, so it does not need to manifest, but it definitely is problem.
I always use the auto-generated id and have never had a problem. You could enforce an object when instantiated to also be persisted using your service layer/factory.
I think the likelihood of any other field (composing a biz key) changing is much more probable than using a non-persisted object in a hashmap and then persisting at the same time causing the look up to fail.
This problem, imho, is somewhat over-analysed. The auto-generated id is often the only test I want to do for equality, nothing else makes sense in a lot of cases. I take the approach that if a non-persisted object is being used/compared the problem is in the business logic and not the underlying equals/hashcode methods
To specifically answer the illegalstateexception idea, throwing an exception when objects are not equal and/or have not been persisted seems rather dramatic.