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
