Sun Proposes Single Persistence Model for Java

Sun Proposes Single Persistence Model for Java
( Page 1 of 2 )

The plan, which could delay the delivery of Java 2 Enterprise Edition 5.0, is to reconcile Java's persistence models, where a single model would run across the Java platform.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."

Java creator James Gosling sounds off on Java futures. Click here to read the interview.

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."

Resource Library:

Next Page: In limbo no longer.

>>> More Application Development Articles          >>> More By Darryl K. Taft