eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Sun Microsystems Inc. has proposed a new, single data persistence model for Java that will combine the core focus of two key specifications and give the Java community a single target to work toward.
In an open letter addressed to the Java Technology Community scheduled for official release Monday morning, but that began getting around last Friday, the leaders of the specifications—EJB (Enterprise JavaBeans) 3.0, JSR (Java Specification Request) 220; and JDO (Java Data Objects) 2.0, JSR-243—Linda DeMichiel and Craig Russell, respectively, explained the reasoning for the “reconciliation effort” and called for community support.
But for all the good news, the move to reconcile Javas persistence models could delay the delivery of the next version of the Java 2 Enterprise Edition specification, J2EE 5.0, if only slightly, Sun officials said.
“The big news to the Java Technology Community is to give people an update on EJB 3.0,” said Dennis MacNeil, product line manager for J2EE at Sun, in an interview with eWEEK. “It [EJB 3.0] is all about ease of use, and as part of that were going to a Plain Old Java Objects [POJO] persistence model.”
In the letter, DeMichiel and Russell said: “For years, the Enterprise JavaBeans (EJB) and Java Data Objects (JDO) specifications have evolved independently as they addressed different sets of requirements. The core of both specifications, however, includes persistence technology. Even to this day, the data persistence models in EJB and JDO differ significantly. This divergence has caused confusion and debates among Java developers, and is not in the best interest of the Java community. Consequently, requests to put an end to this unwanted divide have poured in from members of the Java community. In response to these requests, Sun Microsystems is leading a community effort to create a single POJO (Plain Old Java Object) persistence model for the Java community. This effort will strengthen community solidarity.”
Persistence is a property of programming where objects and data continue to exist and retain their values from session to session or between runs of a program.
Up to this point, conflicting persistence models have been cause for concern, or at least extra work, among Java developers. “Theres no point in having confusing standards out there,” MacNeil said.
The new plans call for “a single model to run across the Java platform—not just J2EE, but also J2SE [Java 2 Standard Edition],” MacNeil said.
In an interview with eWEEK, DeMichiel, who also is a Sun staff engineer, said, “The impetus for the work was to simplify things. … We got such a strong response to the EJB 3.0 work” that the company sought to further assist in simplifying the environment for Java developers, she said. “It is good to converge the efforts.”
When EJB 3.0 was formally announced earlier this year, a swirl of debate around the issue arose with many praising the Sun effort and some asking whether EJB was even necessary.
Rod Johnson, a London-based enterprise Java architect, J2EE consultant and author, was an early critic of EJB 3.0. Yet, Johnson said the idea to converge the data persistence model has promise.
“Ideally I think a new JSR devoted to transparent persistence would have been more appropriate,” Johnson said. “Its odd for EJB3 to be defining a persistence API applicable to J2SE. But overall I think its promising. Everyone seems to agree that transparent persistence is important, and that POJO persistence is the future. The EJB expert group seems finally to accept that persistence should not be tied to the EJB container. Hopefully from here the focus will be on getting a good technical solution, rather than on politics.”
Meanwhile, the open letter also said: “This is a community effort. We are expanding the JSR-220 Expert Group to include some members from the JSR-243 Expert Group. By joining forces, we will bridge the two communities and leverage the know-how in both groups. The current JSR-220 specification lead will remain unchanged.”
Next Page: In limbo no longer.
Page 2
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.
“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.”
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 time—that 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.”
Be sure to add our eWEEK.com Application development news feed to your RSS newsreader or My Yahoo page