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

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.