| JDO vs JPA |
DataNucleus AccessPlatform supports both JDO and JPA specifications of Java persistence. As such it has no "vested interest" in either technology, believing that it is for users to choose which they like best. There has been much FUD on the web about JDO and JPA, largely perpetrated by RDBMS vendors. This FAQ corrects many of these points
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 asJSR243. 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 asJSR220.
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 asJSR243. 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 asJSR220.
Q: Why did JPA come about when we already had a specification for Java persistence in JDO?
Politics. RDBMS vendors 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.
Politics. RDBMS vendors 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 two revisions to the JDO2 specification;
No. As part of SUN's capitulation above, they donated JDO to Apache to develop the technology further. There have been two 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 adding on MetaData/Enhancer APIs as well as query timeout/cancel support 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.
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.
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.
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.
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.
No comments:
Post a Comment