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

Target datastore
: JDO is designed for all datastores, whereas JPA is just
designed around RDBMS and explicitly uses RDBMS/SQL terminology. If using RDBMS then
you have the choice. If using, for example, a NoSQL store then JDO makes much more sense

Datastore interoperability
: are you likely to change your datastore type at
some point in the future ? If so you likely ought to use JDO due to its design

API
: both APIs are very similar. JDO provides more options and control
though for basic persistence and retrieval there are differences only in the namings

Experience
: do your developers know a particular API already ? As mentioned
the API's themselves are very similar, though the metadata definition is different. Remember
that you can use JPA metadata with the JDO API, and vice-versa.

Querying
: do you need a flexible query language that is object-oriented
and extensible ? JDOQL provides this and the implementation in DataNucleus allows
extensions. If you just want SQL then you can use JDO or JPA since both provide this

Fetch Control
: do you need full control of what is fetched, and when ?
JDO provides fetch groups, whereas JPA doesn't. Use JDO if this is an important factor
for your design

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 JDO2 specification;

JDO2.1 adding on support for annotations, enums, and some JPA concepts.

JDO2.2 adding on support for dynamic fetch groups, transaction isolation
and cache control.

JDO3.0 adding on MetaData/Enhancer APIs as well as query timeout/cancel support etc

In addition, JDO3.1 is underway, adding on support for more JDOQL methods, as well as control over
position of a column, size of a sequence, and likely more features to follow.

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 private by an "expert group". 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. 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 run the JDO3 and JPA1 TCKs at frequent intervals and 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.