Persistence API : JDO or JPA ?

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
  • ORM : JDO has a more complete ORM definition, as shown on Apache JDO ORM Guide
  • 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

There is a further comparison of JDO and JPA on technical grounds over at Apache JDO.


Persistence API FAQ

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;

  • 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 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.