The problem of the difficult equals() implementation goes away! If you use the identity map right, you never have to implement equals().
You're now suggesting not to implement equals!? The Hibernate documentation recommends overriding equals() and hashCode() if you're using detached objects, as you're repeated numerous times yourself. In fact, you override these methods in your swingdemo app.
You say you should do this quite clearly here:
It says it in the wiki page on this topic:
It says it VERY clearly in the online documentation:
http://www.hibernate.org/hib_docs/v3/re ... lshashcode
It weakly suggests it may be necessary in HiA:
HiA page 122
And apparently says it clearly in JPwH (previous post).
It seems clear from the documentation that you often do want to override equals. Also, Hibernate is not the only thing that uses equals. Collections use it. Sometimes algorithms use it.
We know there are problems with object identity when objects are persisted. These are not in any way specific to Hibernate, this is true of all persistence frameworks.
It seems to me there are basically 3 ways to implement equals:
1) don't override equals, so if a.equals(b) then a==b
Pros: simple, requires no extra coding
Cons: if you have detached objects in Sets, you have to be very careful not to get a duplicate object from a different Session into the same Set.
2) use a business key to define equals
Pros: solves the above problems, allows you to use simple, Hibernate-managed ids, this is the Hibernate-recommended approach with detached objects that use Sets.
Cons: good business keys may be hard to find due to the changability of most fields, especially when every field in a table is editable from within the app. Requires careful custom coding for each model object.
3) use application-assigned ids (assumes UUIDs to avoid id collisions)
Pros: solves all of the problems from the above 2 approaches.
Cons: uses a longer, slower character-based primary key that inflates database size. Not suitable for large tables, especially if there are lots of foreign keys.
The current documentation only mentions 1 and 2. Both of these have strengths and weaknesses. I've added 3, which also has strengths and weakness as listed above. It works just fine if the size of the ids is not problem. It's very simple to implement and very hard to break. Application developers still have to be careful with their object graphs, but some of the pitfalls are avoided so they spend less time thinking about the persistence framework.
All 3 are viable choices. All 3 have tradeoffs. People should carefully choose which approach fits their application. What's the problem?
BTW, just to clarify I in no way thought of this idea, I just use it. It goes way back, and has been mentioned many times in these forums. In particular there are several references to this idea in the comments of the wiki equals page: