> > 1c. Completely redefine annotations to align completely with JDO xml > > metadata. With this approach, you would not be able to take advantage > > of tools that generate 220 annotations.
I prefer option C. Mixing JDO 2 xml and JPA annotations sounds like JDO is transforming into JPA. However the wave of tools coming with JPA is not inconsiderable. I propose that JDO optionally allow JDO ORM implementations to entirelly use the JPA xml and JPA annotations, which would also allow easy migration from JPA to JDO ;) More, I also think that JDO should optionally allow implementations to use JPQL. Regards, Erik Bengtson Quoting Andy Jefferson <[EMAIL PROTECTED]>: > Hi Craig, > > > 1. Add annotations to persistence capable classes. > > > 1a. Use the 220 annotations including the package names > > and add JDO-specific annotations to them. > > > 1b. Use just the 220 annotation names but repackage them from > > javax.persistence to javax.jdo.annotations or something similar. > > This would give us the opportunity (and the danger) of redefining > > the semantics of some of the annotations without conflicting with > > the 220 spec. For example, we could redefine the default behavior > > of fetching relationship fields from eager to lazy, which cannot > > be done with 1a. > > If we repackage the JPA annotations into say "javax.jdo.annotations" then > wouldn't we lose the advantage of tools that create 220 annotations since > those > tools also add in the necessary imports for such annotations (and they would > be > in different locations) ? so its similar to c). > > > 1c. Completely redefine annotations to align completely with JDO xml > > metadata. With this approach, you would not be able to take advantage > > of tools that generate 220 annotations. > > Certainly a) is the first step since we will need annotations adding for the > non-JPA parts of JDO2. > My preference would probably be to stick to the JPA variants where possible, > and > if they dont fit our needs then we can either copy the JPA variant, or maybe > inherit from them to add on extra fields. > > From an implementation viewpoint there is not much difference in time to > implement a complete set of JDO2 annotations as opposed to JPA + addon-JDO2 > annotations. > > > In addition, a definition of what has the higher priority (annotations, > metadata) > would be required to be added to the spec. For example, use annotations, and > then > metadata would override the annotations specification. As per JPA spec > section 10. > > > > 2. Add support for enums and highly concurrent collections. > > Agreed. I'd include Enum, Calendar, Queue, PriorityQueue as a start. > > > 3. Change signatures of interface methods to be 1.5 friendly. > > For example, the signatures of the makePersistent methods should > > be changed to: > > <T> T makePersistent(T pc); > > <T> Collection<T> makePersistent(Collection<T> pcs); > > <T> T[] makePersistent(T[] pcs); > > Yes. > > > 4. Distribute multiple jar files that represent the 1.5 interfaces. > > The interfaces that are 1.5-specific cannot be packaged in a jar > > file with the 1.3 declarations of the interfaces. > > Right now, the jar is named: > > javax.jdo/jars/jdo2-api-2.0.jar. What needs to change for 1.5? > > Perhaps javax.jdo/jars/jdo2-1.5-api-2.0.1.jar would work. > > There would have to be 2 jars. The above name is fine with me, though may be > more > explicit to call it > javax.jdo/jars/jdo2-jdk1.5-api-2.0.1.jar > so people know what the 1.5 stands for. > > -- > Andy >
