Hi Geoff, On May 21, 2005, at 12:53 PM, Geoff hendrey wrote:
Department.hashCode method is using a persistent field to compute the value of the hashcode, in TCK11. Note that in the Sun version of the TCK, which JDOMax passes, hashCode is NOT overidden for Department. I think it is wrong to override hashCode and equals for any class using datastore identity.
The decision to override hashCode and equals belongs to the application, not to the JDO implementation. These methods implement the application's notion of equality, which as is well-described in the JDO specification, is different from both identity (the JVM's way of distinguishing whether two instances are the same) and JDO identity. That's why we have JDO identity.
This was the subject of 35 or so emails on the experts group, and this was the position espoused by Craig. Craig laid down the law: "If you don't have a set of fields that uniquely form an application identity, then you should not implement equals. You *should* delegate to Object.equals"
The classes in question have a set of fields that uniquely form an application identity, and hashCode and equals use these fields. I don't see the issue.
Please let me know if an implementation is expected to handle cases when the user overides equals and hashCode for datastore identity?
Yes. The three forms identity, equality, and JDO identity are given equal weight in the Java specification, the java.util classes, and the JDO specification. Identity belongs to the VM; equality belongs to the application; JDO identity belongs to the implementation.
Craig
Certainly, JDOMax
does NOT, and is failing a good bit of the Apache
TCK11 because of it!
-geoff
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
