A single POJO persistence model to replace JDO and take over much of EJB??

3

Java and persistence are hot. And continue to be hot.

If I read things correctly, Sun – through Linda DeMichiel and Craig Russell Specification Leads, JSR-220 and JSR-243 – is letting us know that:

  • there will be a standard for Object/Relational mapping and persistence of POJOs: JSR 220
  • it will be part of J2EE 5.0 and perhaps J2SE x.y as well
  • it draws from current offerings such as Hibernate, Oracle Toplink and JDO
  • it will provide the core of EJB 3.0 implementations
  • it will include support for inheritance,polymorphic relationships,and automatic persistence of instances in relationships with persistent instances. Persistence is not tied to remote behavior and persistent instances are not components. Fine-grained transaction and security models are not part of the persistence models.
  • it will effectively replace JDO: “the new POJO persistence API is what you’ll see in J2EE 5.0.This approach will be adopted by the J2EE platform vendors,since it’s part of the EJB3.0 specification,and it is the approach that we recommend that JDO and other persistence API vendors also leverage.
  • it will provide the core of EJB 3.0 implementations
  • it will not specifically support mapping to non-relational data stores; “the use of JSR 220 APIs for non-relational data stores will not be disallowed.

My Conclusions


To me this sounds as: JDO is a dead-end street. JSR-220 will result in a new standard for Bean-to-Relational mapping, much as JDO, Hibernate and TopLink do today – but in a newly designed manner. EJBs are not doing well at all. By basing EJBs on a widely supported standard persistency architecture – i.e. JSR 220 – SUN hopes to get EJBs off to a new start. I would not investing in JDO or EJB at this point. Use of Hibernate or Toplink seems a much better bet; they are sound and up to speed right now and if and when this JSR-220 API is released and takes off, there will probably an easy migration path.

Background

In an open letter to the Java Technology Community Linda DeMichiel and Craig Russell Specification Leads, JSR-220 and JSR-243, explain there strategy for the near future.

Craig Russel further elaborates on the situation in this interview with JDOCentral.com.

Sun has listened to the persistence community and decided that a common persistence interface,based on a lightweight POJO domain object model,that works both within J2EE and with J2SE,is the best overall persistence solution. This interface will provide many of the advantages of JDO,and it does not rely on entity beans for persistence.

The persistence interface being developed by JSR 220 will be a standard,and will not be based on any existing persistence framework.We are drawing upon ideas contributed by many popular frameworks,including JDO,Hibernate,TopLink,and others.We expect once the standard becomes final,the majority of these vendors will provide compatible implementations.

SUN itself does not belief EJBs ever were the standard for O/R Mapping:

One of the challenges to adoption of O/R mapping has been the lack of a standard. With this new standard in place,the quality of implementations will help us reduce this skepticism.In the long run,the desire for portability across databases and platforms,in combination with a well designed standard,are key to widespread adoption of the O/R mapping and this new persistence API.

We will promote this new API as the preferred standard upon which you should build solutions.We’ll encourage persistence API vendors including JDO vendors and EJB endors to develop migration strategies to help de elopers move to this new API.

See: The Unofficial EJB 3.0 (JSR-220) FAQ by Debu Panda for more details and a more informed review of the situation:

What is target release for EJB 3.0 and the new persistence specification?

The original target release of EJB 3.0 (and J2EE 5.0) was summer of 2005. Certainly this date will be impacted by the unification of persistence specification.

What will happen to old-style (EJB 2.1 and EJB 2.0) CMP Entity Beans?

EJB 3.0 compliant containers for backward compatibility will still support the old style CMP Entity beans. Also EJB 3.0 plans to extend the EJB-QL for the EJB 2.1 style CMP entity beans.

The future of CMP: .Simplify Container Managed Persistence – CMP Entity Beans will resemble POJO based persistence

  • Support for lightweight domain modeling, including inheritance and polymorphism.
  • Specification of Java language metadata annotations for the object/relational mapping of Entity beans with container-managed persistence.
  • Enhancements to EJB QL to provide greater usability. Addition of projection, explicit inner and outer join operations, bulk update and delete, sub queries, and group-by. Addition of adynamic query capability and support for native SQL queries.

Also see this post on The Server Side, with a lot of discussion, as usual. This reply has Rod Johnson’s take on the situation.

Share.

About Author

Lucas Jellema, active in IT (and with Oracle) since 1994. Oracle ACE Director for Fusion Middleware. Consultant, trainer and instructor on diverse areas including Oracle Database (SQL & PLSQL), Service Oriented Architecture, BPM, ADF, Java in various shapes and forms and many other things. Author of the Oracle Press book: Oracle SOA Suite 11g Handbook. Frequent presenter on conferences such as JavaOne, Oracle OpenWorld, ODTUG Kaleidoscope, Devoxx and OBUG. Presenter for Oracle University Celebrity specials.

3 Comments

  1. Very interesting interview on The Server Side with Mike Keith and Doug Clarke from the Oracle Toplink team: TopLink: 10 Years of Persistence.. It talks about EJB 3.0 and why Oracle left the JDO group. Also what differentiates Toplink from Hibernate and SolarMetric.

    Mike: TopLink brings with it a strong history and long track record in this market. It is proven, scalable technology that has its feature set evolved from use by thousands of customers building challenging, diverse applications. After 10 years, we have the richest, most powerful feature set available and can address very sophisticated requirements.

    Another major differentiating factor is we offer functionality beyond a pure O/R mapping product. We provide the ability to map to XML and other types of non-relational data. TopLink brings much more to the table in terms of the complete data integration story than it ever has before. It is very exciting actually, because as we offer bigger and better solutions it also keeps it interesting for us at the development level. TopLink has proven itself as a leading and visionary product and has lead the way in O/R mapping for a decade, now. We will continue to show leadership as the problem space expands.

  2. I am a JDO vendor on both the JDO 2 and JSR 220 expert groups. I’m excited about the opportunity to create a common persistence API for Java, but I have to disagree with you that JDO is a dead end. JSR 220 is due to ship with J2EE 1.5 in 2006, while JDO 2 will be out in a few months. JDO 2 is an extremely full-featured spec with excellent ORM. Most JDO vendors will continue to support JDO 2 for the foreseeable future, since it already contains as least as much functionality as is slated for the eventual JSR 220 spec. Who knows; JDO might even advance after JDO 2 as a superset of JSR 220!

    And even if I cannot convince you that JDO is not a dead end, it is still a standard today. That means that you can freely switch between the multiple vendors out there, and take advantage of the vendor that comes out with the best migration tools to switch to the new API once J2EE 1.5 is released in 12-15 months. So even if you believe JDO is a dead-end spec, it still has advantages over using a product that doesn’t adhere to any spec at all.

  3. Zeger Hendrikse on

    After reading this post, I got a much better idea on the current situation of the “ORM market”. Great!