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 th
ose
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, meta
data)
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 secti
on 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

[ Post a follow-up to this message ]

> > 1c. Completely redefine annotations to align completely with JDO xml 

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 <andy@jpox.org>:
[vbcol=seagreen]
> Hi Craig,
> 
> 
> 
>
> 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 wou
ld
> be
> in different locations) ? so its similar to c).
> 
>
> Certainly a) is the first step since we will need annotations adding for t
he
> non-JPA parts of JDO2.
> My preference would probably be to stick to the JPA variants where possibl
e,
> and
> if they dont fit our needs then we can either copy the JPA variant, or may
be
> 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-JDO
2
> 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, a
nd
> then
> metadata would override the annotations specification. As per JPA spec
> section 10.
>
> 
>
> Agreed. I'd include Enum, Calendar, Queue, PriorityQueue as a start.
> 
>
> Yes.
> 
>
> 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
>

[ Post a follow-up to this message ]

> I prefer option C. Mixing JDO 2 xml and JPA annotations
> sounds like JDO is transforming into JPA

After further review of the JPA annotations definition, and the amount of
configuration missing from JPA, I'm now tending towards option C also. It's 
not
like JPA has even the basic properties covered, which they don't. There are 
too
many concepts missing from JPA (not to mention the differing terminology) so
 JDO
would be defining its own annotations to a high degree anyway, so why not ju
st be
done with it and define JDO annotations?

Clearly any implementation of JDO/JPA can implement their own support for JP
A
annotations, but from a purely specification point of view JDO annotations n
eed
to be complete and matching what the metadata provides control over, hence i
ts
own set.


--
Andy

[ Post a follow-up to this message ]

For information, you can find an initial (top-level) set of suggested JDO2
annotations at
http://jpox.cvs.sourceforge.net/jpo...ati
ons/
in case JDO2 decides to adopt its own annotations.

The aim with these is to retain the mapping MetaData<->Annotation (which is 
what
JPA does, just they dont have such generalised MetaData so cant specify thin
gs
that we need). The main annotations are

@PersistenceCapable
class MyClass
{
@PersistentField
String myField;

..
}

@PersistenceAware
class MyAwareClass
{
..
}

The "class" metadata element maps to the "PersistenceCapable" annotation. Th
e
"field" metadata element maps to the "PersistentField" annotation. The only 
place
where this differs in this sample set is that I split out "PersistenceAware"
 as
its own annotation.

--
Andy

[ Post a follow-up to this message ]

> For information, you can find an initial (top-level) set of suggested JDO2
> annotations at
http://jpox.cvs.sourceforge.net/jpo...ati
ons/

Since it's all quiet on annotations I'll provoke further :-)
The above link now shows an almost complete set of proposed JDO2 annotations
(I changed "PersistentField" to "Field" to match the metadata element). The
advantages of matching annotations to metadata element are obvious ... peopl
e
don't need to relearn the terms they already know from metadata. The only
places where I haven't stuck to this are the top-level PersistenceCapable,
PersistenceAware annotations (since they make more sense, to me)

The only elements missing are Index, ForeignKey, Unique (i'll add these soon
),
Interface, Property (which are low interest for me) and the recursive aspect
s
of FetchGroup and Embedded (which are restricted due to annotations JDK1.5
design). Needless to say that these are all supported in the latest JPOX
nightly builds where you could actually use them interchangeably with your
metadata, or JPA annotations, or indeed your own set of annotations if you
feel like it.

Comments are welcome. Really.


--
Andy

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

After reviewing Andy's proposal and the relevant page on JPOX website
I vote for:
2. Define a complete set of annotations - based on JPOX current work
And IMO, this should be a required feature.

Ilan



----- Original Message ----- 
From: "Craig L Russell" <Craig.Russell@sun.com>
To: <jdo-dev@db.apache.org>
Cc: <jdo-experts-ext@sun.com>
Sent: Wednesday, July 12, 2006 7:36 PM
Subject: Re: JDO2 Annotations


> Javadogs,
> 
> Please take a look at this proposal by Andy.
> 
> High order bit: The expert group needs to make a decision whether to:
> 
> 1. Not define any annotations, leaving it up to implementations to  
> decide what to do
> 
> 2. Define a complete set of annotations
> 
> 3. Track JSR 220 and JSR 250 annotations for persistence and mapping  
> and add only annotations for JDO that are not already covered by the  
> other annotation specifications
> 
> Orthogonal to the above, we need to decide whether support of  
> annotations for implementations that support JDK 1.5 is required or  
> optional.
> 
> Craig
> 
> On Jul 4, 2006, at 11:48 PM, Andy Jefferson wrote:
>  
> 
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

I believe option 2 is most appropriate for JDO. JDO, really, is actually muc
h
more behavioral predictable than JSR 220, so it really deserves its own
annotation.

However, implementations may just be capable to understand JSR 220 for confo
rt
of the end user. Mostly to help then to "kind of" migrate from JPA to JDO,
particulary I'm refering to usage of the JPA tools that will generate JPA
annotations that could be used by JDO implementations.

> Orthogonal to the above, we need to decide whether support of
> annotations for implementations that support JDK 1.5 is required or
> optional.

I would say yes, speaking for Andy (Andy implemented the annotations stuff),
 it
was very easy to implement, and in a question of days. I abstain in case of
vote, just in case.

Still I would say add another option:

> 4. Track JSR 220 and JSR 250 annotations for persistence.
and mapping. Have only what is already there and thats all (besides vendor
things)

JPOX is supporting fully or partially option 1 (since 2 is not standard), 3 
and
4.

Regards,

Quoting Craig L Russell <Craig.Russell@sun.com>:

> Javadogs,
>
> Please take a look at this proposal by Andy.
>
> High order bit: The expert group needs to make a decision whether to:
>
> 1. Not define any annotations, leaving it up to implementations to
> decide what to do
>
> 2. Define a complete set of annotations
>
> 3. Track JSR 220 and JSR 250 annotations for persistence and mapping
> and add only annotations for JDO that are not already covered by the
> other annotation specifications
>
> Orthogonal to the above, we need to decide whether support of
> annotations for implementations that support JDK 1.5 is required or
> optional.
>
> Craig
>
> On Jul 4, 2006, at 11:48 PM, Andy Jefferson wrote:
> 
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>

[ Post a follow-up to this message ]

Hello Craig and all

 

Here is why we support option 3:

 

*	we think that annotations are nice for persistence but not for mapping inf
ormation

*	so annotation should remain as simple as possible and stay data source ind
ependent
*	one goal of a persistence tool is to remove technical APIs to access data 
sources from business applications source code, mapping annotations are a mo
ve backward in that case. Moreover, they tend to make the source code unread
able as it is cluttered with dozens of interpreted comment lines

*	it is important for users to have a kind of convergence between JDO and JP
A in the future

*	to that extent defining a set of completely different annotations is not d
esirable
*	my guess is that ORM tools will have to support both JDO and JPA in the fu
ture so it is better to implement only one set of annotations (maybe with ad
ditional JDO2 annotations whenever required)
*	to me JDO2 is already a superset of JPA, so JDO annotations should be a su
perset of JPA annotations

 

Best Regards,

....: Eric Samson, Founder & CTO, xcalia

Service your Data!

________________________________

De : Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM] 
Envoyé : mercredi 12 juillet 2006 22:06
À : Apache JDO project
Cc : JDO Expert Group
Objet : Re: JDO2 Annotations

 

Hi Matthew,

 

With hindsight, do you think that this is the right solution? Any insights f
rom your implementation and usage experience whether it was a good or bad id
ea?

 

Craig

 

On Jul 12, 2006, at 1:02 PM, Matthew T. Adams wrote:





Xcalia supports option 3, reusing JSRs 220 & 250 annotations and defining ad
ditional ones as necessary.

--matthew

----- Original Message ----
From: Ilan Kirsh <kirsh@objectdb.com>
To: Craig L Russell <Craig.Russell@Sun.com>; jdo-dev@db.apache.org
Cc: JDO Expert Group <jdo-experts-ext@Sun.com>
Sent: Wednesday, July 12, 2006 12:06:55 PM
Subject: Re: JDO2 Annotations

After reviewing Andy's proposal and the relevant page on JPOX website

I vote for:

2. Define a complete set of annotations - based on JPOX current work

And IMO, this should be a required feature.

Ilan

----- Original Message -----

From: "Craig L Russell" <Craig.Russell@sun.com <mailto:Craig.Russell@sun.com
> >

To: <jdo-dev@db.apache.org <mailto:jdo-dev@db.apache.org> >

Cc: <jdo-experts-ext@sun.com <mailto:jdo-experts-ext@sun.com> >

Sent: Wednesday, July 12, 2006 7:36 PM

Subject: Re: JDO2 Annotations

 

> Javadogs,
> 
> Please take a look at this proposal by Andy.
> 
> High order bit: The expert group needs to make a decision whether to:
> 
> 1. Not define any annotations, leaving it up to implementations to 
> decide what to do
> 
> 2. Define a complete set of annotations
> 
> 3. Track JSR 220 and JSR 250 annotations for persistence and mapping 
> and add only annotations for JDO that are not already covered by the 
> other annotation specifications
> 
> Orthogonal to the above, we need to decide whether support of 
> annotations for implementations that support JDK 1.5 is required or 
> optional.
> 
> Craig
> 
> On Jul 4, 2006, at 11:48 PM, Andy Jefferson wrote:
>  
> 
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo <http://j
ava.sun.com/products/jdo> 
> 408 276-5638 mailto:Craig.Russell@sun.com <mailto:Craig.Russell@sun.com> 
> P.S. A good JDO? O, Gasp!

 





 

Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

408 276-5638 mailto:Craig.Russell@sun.com

P.S. A good JDO? O, Gasp!

 

[ Post a follow-up to this message ]