Cedric Beust, an enterprise Java architect and member of both expert groups, said, "This is fantastic news for then entire community. Ever since the JDO spec came out, developers have been confused as to which framework they should use, and Sun has never been able to give a consistent answer. The Java persistence field has been in limbo for much too long, and this decision is finally going to put an end to it. I am quite confident that this time, the technology that will come out of this merge will solve the O/R [object/relational] mapping problem once and for all." In addition, "The work to define a single POJO persistence model for the Java community will be done under JSR-220 starting from the existing JSR-220 Early Draft," the open letter said. And, "The new POJO persistence model will be delivered by JSR-220 as a separate specification, Reference Implementation, and Technology Compatibility Kit, usable independently of EJB 3.0," the letter added.Where exactly is Java technology is going? Read this eWEEK Labs analysis. Also, according to the letter, "The technical objective for this new POJO persistence model is to provide a single object/relational mapping facility for all Java application developers that works in both J2SE and J2EE. The work will be done within the J2EE 5.0 time frame." "This means that J2EE 5.0 will be shipping around the first quarter of 2006," MacNeil said. "Its a slight adjustment. Initially, we were saying the end of 2005, but now were saying early 2006." Marc Fleury, CEO of Atlanta-based JBoss Inc., said, "Basically I am just happy that EJB3 persistence will be the standard and that the JDO guys will be bringing expertise." "This is a good opportunity for the Java community," said Patrick Linksey, chief technology officer of SolarMetric Inc., of Austin, Texas, which sells the Kodo object/relational mapping tool. "By building a team that is comprised of people from both the EJB and JDO expert groups, Sun has established a new body that will drive collaboration and friendly competition between the two specifications. This will provide a number of persistence options that will meet the needs of the community while also ensuring compatibility among the choices. As members of both JSRs [220 and 243], SolarMetric will provide support for both the JDO framework and this new specification in the Kodo product suite, providing our customers with flexibility and choice." "This sounds like a great step forward, acknowledging what most of us have realized for some timethat the data access portion of EJB and the underpinning of the JDO standard deserve to share a common standard," said Cameron Purdy, president of Tangosol Inc., of Somerville, Mass., which offers its Coherence data management solution for enterprise Java applications. "It will mean a simpler technology choice for our customers, many of whom have asked us whether they should be planning for JDO v2 or Entity EJB v3 for their data access needs in their enterprise applications. It also shows that, when the spotlight isnt focused too brightly on the industry participants, the cooler heads among them can prevail, and end up working together to avoid over-complicating the set of choices that customers have to face. The best part for Tangosol is that we will be able to support clustered transactional data caching for enterprise data access behind one common API, which means we can focus on real customer problems without the distractions of which API to support first." Check out eWEEK.coms Application Development Center for the latest news, reviews and analysis in programming environments and developer tools.
"The persistence model will be an implementation of what weve done in the EJB expert group," DeMichiel said. The model will express the commonalities among the lightweight persistence options in the industry, she said. It will include "influences from TopLink and Hibernate communities, and were now drawing the JDO community on-board."