JDO2 Annotations

[Andy Jefferson <an...@jpox.org>]

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

Re: JDO2 Annotations

[Erik Bengtson <er...@jpox.org>]

> > 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 <an...@jpox.org>:

> 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
>