The equals method gen'd by hbm2java includes the primary key in the equals test. This makes sense for an object that has been persisted.

However, it prevents adding several new instances of a class to a set (Map) prior to saving.

I have hacked around it by commenting-out the gen'd equals method.

How should this be handled?

first - this is tool related and should be in the tools forum instead ;)

Secondly - yes, equals() is pretty hard to implement on objects which identity changes while inside a Collection since that is illegal according to the Collection API ;(

...I've not yet came up with a good solution for it....one way is just to not override equals and thus fallback on '=='-comparisons instead.

Depending on the implementation, you should be able to change an object in a Collection but you should not change an object in place in a Set. That means that you cannot change the key for your Map. I am assuming this occurs for a mapping that has a native id. I haven't used maps very often with Hibernate but I have ran into the same problem sevaral times with a Set. I get around it by changing the equals test to include a candidate key and if there is no candidate key I use all columns except the id if the id is not set. Remember to keep your hashCode method in sync with equals so that equal objects always return the same hash code.

If you use all columns or the key then the check will most likely change when in a set....won't it ?

That hasn't been a problem in practice because I usually build up the object, add it to the set, and commit. I am not sure how hibernate avoids the problem when it sets the id from the natively generated key but it hasn't caused any errors.