Re: Question on TCK11
The test in question used DatastoreIdentity. you said: "The classes in question have a set of fields that uniquely form an *application identity*" and I'm just saying no, they don't form an *application identity*, because this test doesn't use application identity. It uses Datastore Identity. Ho hum, I guess I'm just grumpy because I didn't expect the Apache TCK to be so different from the Sun TCK. -geoff --- Craig Russell <[EMAIL PROTECTED]> wrote: > Hi Geoff, > > It sounds like you are confusing application > equality with JDO > identity, which are two separate concepts. > > JVM has identity that you test with a == b. > > Applications have equality that you test with > a.equals(b). > > JDO has identity that you test with > a.getObjectId().equals(b.getObjectId()). > > Three different concepts. > > Craig > > On May 21, 2005, at 6:37 PM, Geoff hendrey wrote: > > > > >> 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. > > > > DatastoreIdentity is used, so no, they don't form > an > > application identity. > > > > -geoff > > > > > > > > > > > > > > > > > > Discover Yahoo! > > Find restaurants, movies, travel and more fun for > the weekend. Check > > it out! > > http://discover.yahoo.com/weekend.html > > > > > 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! > Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/
Re: Question on TCK11
> 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. DatastoreIdentity is used, so no, they don't form an application identity. -geoff Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html
Re: Question on TCK11
Hi Geoff, It sounds like you are confusing application equality with JDO identity, which are two separate concepts. JVM has identity that you test with a == b. Applications have equality that you test with a.equals(b). JDO has identity that you test with a.getObjectId().equals(b.getObjectId()). Three different concepts. Craig On May 21, 2005, at 6:37 PM, Geoff hendrey wrote: 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. DatastoreIdentity is used, so no, they don't form an application identity. -geoff Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html 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
Re: Question on TCK11
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
Question on TCK11
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. 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" Please let me know if an implementation is expected to handle cases when the user overides equals and hashCode for datastore identity? 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
