Note that one of my -'s for option 2 is that you cannot put them into
a collection...
Using @Id for hashcode is OK as long as you persist objects before
putting them in a HashSet.
How do you handle the case where business keys change?
On Dec 14, 2007 8:08 PM, <glassfish_at_javadesktop.org> wrote:
> WIth option 2 you still probably don't want to use the @Id field in hashCode. @Id is normally set when you initially save an object, which means that hashCode will change at this point. Confusion will ensue.
>
> I normally use business keys in both hashCode and equals, but add @Id in equals. This is complex, but correct.
>
> Furthermore: With any option, I have regrettably found it necessary to do an "instanceof" test instead of the recommended "getClass() == getClass()" test (from Effective Java). This is to support the subclassing that happens with lazy loading.
> [Message sent by forum member 'jhannes' (jhannes)]
>
> http://forums.java.net/jive/thread.jspa?messageID=250199
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>