There are two standard API's for persistence in Java - Java Data Objects (JDO) and Java Persistence API (JPA). JDO is designed for all datastores, and JPA is designed for RDBMS datastores only. DataNucleus supports both, fully, and also provides support for a REST API. When choosing the persistence API to use in your application you should bear the following factors in mind
There is a further comparison of JDO and JPA on technical grounds over at Apache JDO.
To supplement the factors above to bear in mind when choosing your persistence API, there has been much FUD on the web about JDO and JPA, largely perpetrated by RDBMS vendors, and we provide a FAQ that corrects many of these points so you can base your decision on what is best for you
Q: Which specification was the original?
JDO was the first Java persistence specification, starting in 1999, and the JDO 1.0
specification being published in April 2002. This provided the persistence API, and
was standardised as JSR012.
In May 2006 JDO2 was released. This provided an update to the persistence API as
well as a complete definition of ORM, standardised as
JSR243.
Later in May 2006 JPA1 was released. This provided a persistence API, and a limited
definition of ORM, concentrating only on RDBMS, and was standardised as
JSR220.
Q: Why did JPA come about when we already had a specification for Java persistence
in JDO?
Politics. RDBMS vendors apparently didn't like the idea of having a technology that allowed
users to leverage a single API, and easily swap to a different type of datastore. Much
pressure was applied to SUN to provide a different specification, and even to try
to say that JPA was to supercede JDO. The JCP is dominated by large organisations
and SUN capitulated.
They even published a "FAQ"
to try to justify their decision.
Q: Is JDO dead?
No. As part of SUN's capitulation above, they donated JDO to
Apache to develop the technology further.
There have been the following revisions to the JDO specification;
In addition, JDO3.1 is reaching its conclusion, adding on support for more JDOQL methods, as well as control over position of a column, size of a sequence etc.
Q: Will JPA replace JDO ?
It is very hard to see that happening since JPA provides nothing to cater for persistence
of Java objects to non-RDBMS datastores (LDAP, ODBMS, XML, ODF, Excel etc).
It doesn't even provide a complete definition of ORM, so cannot yet compete with JDO's
ORM handling. Even in JPA2 (final in late 2009) there are still basic ORM concepts
that are not handled by JPA yet JDO standardises them.
JDO is still being developed, and while users require this technology then it will continue
to exist. DataNucleus will continue to support both APIs since there is a need for both
in modern enterprise applications despite what Oracle, IBM, et al try to impose on you.
Q: What differences are there between how JDO is developed and how JPA is developed ?
JPA is developed in isolation by an "expert group" though in JPA2.1 they have added a mailing list
so you can see their discussion (not that they'll reply to input necessarily).
JDO is developed in public by anybody interested in the technology.
The tests to verify compliance with JPA are only available after signing non-disclosure agreements
with SUN and this process can take up to 3 months just to get the test suite (if ever).
The tests to verify compliance with JDO are freely downloadable and can be run by users or developers.
This means that anybody can check whether an implementation is compliant with JDO, whereas the same
is not true of JPA.
DataNucleus runs the JDO3.x and JPA1 TCKs at frequent intervals and we publish the results
on our website. DataNucleus has been prevented from accessing the JPA2 TCK (by Oracle and
the JCP, documented in our blog).
Q: Why should I use JDO when JPA is supported by "large organisations" ?
By "large organisations" you presumably mean commercial organisations like Oracle, IBM,
RedHat. And they have their own vested interest in RDBMS technologies, or in selling
application servers. You should make your own decisions rather than just follow down the path
you are shepherded in by any commercial organisation. Your application will be supported
by you not by them. The technology you use should be the best for the job and what
you feel most comfortable with. If you feel more comfortable with JPA and it provides all
that your application needs then use it. Similarly if JDO provides what you need then you
use that. For this reason DataNucleus provides support for both specifications.