db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jordan <davej...@bellsouth.net>
Subject Re: The Future of JDO
Date Thu, 05 Oct 2006 10:50:15 GMT

One other thing I forgot to mention last night...

Just in the last two weeks there was some discussion among the  
members of the local Java User's Group. A few people were complaining  
about how difficult and frustrating it was using Hibernate, due to  
some of its limitations. They were frustrated there were no  
alternatives to Hibernate. JDO does not have the problems that they  
were experiencing with Hibernate. So I responded to the discussion  
saying JDO did not have those weaknesses of Hibernate, JDO is a  
standard, and JDO has a great free reference relational  
implementation in JPOX if they needed it to be free.

First, they thought JDO was no longer being worked on, they did not  
seem to believe me that the JDO expert group was still actively  
refining the standard. They referred to the letter that included the  
names of Craig and Linda that Sun published back when we were first  
told about JPA. It would help if Craig could publish something that  
would indicate that the JDO standard is continuing to evolve. It  
would also be good to have statements from implementers discussing  
continued adoption of the implementations, so people have written  
proof JDO is still alive, evolving, and being used.

Many had never heard of JPOX. There needs to be some articles  
published on the Web and in magazines which focus on JDO and JPOX. I  
have said this before, marketing of JPOX as the free open source  
relational implementation will do more to drive sales of commercial  
implementations than anything else. (Andy has not paid me to say  
this!) Everyone has heard of Hibernate, but most have not heard of  
JPOX. Maybe even an article that does some comparisons of Hibernate,  
JDO, and JPA relative to building a small application will drive some  
points home.

The fact that JPA has not really had much impact (that is the  
perception out there, I don't know the reality, but in the market it  
is perception that matters) does give JDO a new opportunity to rise  
up and be reconsidered.

On Oct 5, 2006, at 1:08 AM, Andy Jefferson wrote:

>> I continue to believe that the largest backers of JPA were against
>> JDO because of it being binary compatible across object and
>> relational databases.
> Agreed.
> JPA was "invented" to be so weak that Hibernate and TopLink could be
> considered "standards compliant" and to water down any such  
> specification to
> allow such RDBMS vendors (you know who they are) to continue to  
> lock clients
> in to their bloated RDBMS ... another reason why the JDBC  
> "specification" is
> also so weak (and it has had *many* revisions) and doesn't define  
> so many
> things (and why the JDBC drivers of aforementioned RDBMS vendors  
> are so poor
> at implementing that "specification").
>>> If, however, JDO 3.0
>>> will extend JPA in some way - we might be in a similar position
>>> as Hibernate and Toplink that also support their old API in
>>> addition to the new JPA API, with the advantage that our extensions
>>> are standard and backed by multiple implementations including both
>>> relational databases and object databases (plus some unique
>>> powerful features such as JDO 2.0 fetch groups).
>>> Maybe some JPA issues can be excluded. But in my opinion at least
>>> supporting the new API (e.g. deprecating makePersistent and adding
>>> persist, or supporting both as in java.util.Vector since JDK 1.2)
>>> is a must in order to survive.
> Totally agree. I would think of the following items
> 1. "persistence.xml". I see no real reason not to allow  
> specification of
> classes to be persisted using persistence.xml as an additional way of
> creating the PMF.
> 2. Persistence API. There are not many differences between JPA and  
> JDO methods
> so what you propose should be straightforward. Those JDO  
> implementations that
> have/are implementing JPA will know that it is simply putting a  
> wrapper
> around their existing JDO method. Why not include in 2.1?
> 3. Query Language. JPQL can be made available via the query  
> "language" flag in
> the existing API (so we add "javax.jdo.query.JPQL" or something as  
> a valid
> value). OK the JDO implementation (if supporting this language)  
> will have to
> add a new query language but the hook is there. Could be an  
> optional feature
> in JDO 2.1 ?
> 4. Types. Mandate support for Enums, Calendar when running under  
> Java5, so all
> types that JPA supports are there. Why not include in 2.1?
> 5. Annotations. The donated JDO2 annotations need splitting between
> persistence annotations, and ORM. Looking through the JPA  
> annotations some
> time ago, it wasn't clear that we can just take theirs and add  
> others due to
> too many missing concepts. What the JDO(3) spec could do is firstly  
> define
> the precedence of annotations and metadata (to match the JPA spec
> definition), and secondly define how JPA annotations can be used by  
> a JDO3
> implementation. In addition provide JDO2/3 annotations to allow finer
> definition.
> -- 
> Andy

View raw message