Public plea to the EJB 3.0 expert group: Please review the EJB 2.0 CMP and JDO FAQ
Lance Anderson's recent blog "
EJB 3.0 Spec is available for Early Draft Review" got me fired up again. My apologies in advance for sounding like a broken record, but I just can't help it.
I believe that Sun's EJB 2.0 CMP and JDO FAQ by Mark Hapner and Craig Russell makes a good case for embracing JDO as the standard persistence mechanism for EJB Entity Beans.
This excellent FAQ points out the relationships between EJB Entity Beans and JDO, and gives insight into the reasons that JDO wasn't embraced at the time.
From the FAQ:
"There has been a long history of debate between proponents of persistence that uses the functional approach vs. language transparent persistence. The debate about CMP vs. JDO is just another chapter in this book. The EJB expert group was willing to accept EJB function based persistence as a requirement but not Java transparent persistence." (I added the emphasis)
Clearly, the EJB expert group has now reversed their position on transparent persistence. The rationale for rejecting JDO is no longer valid.
There is a standard for Java transparent persitence, and the EJB expert group ought to embrace it.
When the JSR#243 (JDO 2) was voted on, IBM voted no. IBM's comments were as follows:
"This JSR proposes to develop extensions to JDO that apparently overlap with existing Java technologies and with other JSRs that are already in-progress.
In a context where the Java community is working to simplify J2EE, it is undesirable to produce multiple overlapping ways of programming the same function."
I completely agree with the second statement, but not with the first.
With respect, it is the EJB 3.0 draft specification that is overlapping with an existing Java technology. JDO, the standard for Java transparent persistence, pre-dates the EJB 3 efforts, not the other way around.
Java needs one standard for transparent persistence. If JDO is broken, fix it.
For a great vision of a world where EJB and JDO cooperate, check out Dion Almaer's blog.