The surprise announcement on the first day of EclipseCon 2008 was that Eclipse rival Sun Microsystems Inc. selected the Eclipse Persistence Services Project (EclipseLink), led by Oracle Corp., as the reference implementation for the Java Persistence API (JPA) 2.0.
Although the Eclipse Foundation and Sun are vying for the hearts and minds of Java coders, the two along with Oracle, which is a member of Eclipse and a partner of Sun, are cooperating on the new version of JPA, designated JSR 317 in the Java Community Process (JCP).
The team effort by Sun, Oracle and Eclipse is notable because Sun is not a member of Eclipse. Analysts for the Burton Group Inc. and other firms have suggested that Eclipse may be the platform of choice for service-oriented architecture (SOA) projects as opposed to Sun's Java Enterprise Edition. This explains the rivalry between Sun and Eclipse, characterized by the pun in the latter's name.
But perhaps a team of rivals is possible in the open source world.
"This is great for the Java community as a whole," said Dennis Leung, vice president, development at Oracle Corp., and a spokesman for the EclipseLink project. "It's great for Oracle and Sun to be working on this as partners. Obviously this is great for the JCP and Eclipse communities. It is the first Java EE reference implementation done at Eclipse. I think it's a very significant announcement. It's a big step for Eclipse, the JCP, Sun and Oracle. This is a great step forward in cooperation."
However, Anne Thomas Manes, vice president and research director at Burton Group, does not see this as any sort of reconciliation between Sun and Eclipse.
"I don't think this represents a move by Sun to join/endorse/get-warm-and-fuzzy with Eclipse," she said. "I suspect Sun is happy that the Eclipse Foundation is participating in a JCP effort. Much of what goes on at Eclipse never finds its way into formal Java standard APIs. This situation is a case of historical rather than new precedent. Oracle provided the reference implementation of JPA 1.0 based on its TopLink implementation. Oracle has since moved this effort to Eclipse, the EclipseLink project. Sun would have had a huge PR issue on its hands if it had refused to allow Oracle to provide the v2 reference implementation just because it's being developed at Eclipse."
Bradley F. Shimmin, principal analyst of application infrastructure at Current Analysis LLC., agreed that the announcement isn't a game changer for Sun and Eclipse, but he does see it as a plus for the larger open source community.
"I don't think this announcement by itself indicates a change of vision for Sun regarding its relationship with Eclipse as a development platform," Shimmin said. "Though Sun works with the Eclipse community and creates points of interoperability between Eclipse and NetBeans environments, the company is still dedicated to NetBeans. This announcement speaks primarily to Sun's interest in furthering the Java platform through the addition of a very well-regarded persistence engine. More broadly, this announcement underscores the power of an engaged and empowered open source community as an agent of innovation that does not recognize corporate boundaries."
EclipseLink is not the only project where Sun has cooperated with Eclipse, noted Sun distinguished engineer Eduardo Pelegri-Llopart, but he characterized it as an evolutionary step. He noted that the Eclipse Europa, last June's annual release of Eclipse tool projects, supported GlassFish. Members of the GlassFish team worked with Eclipse project teams on that support, he said.
"We've always had a relationship," Pelegri-Llopart said. "This is an evolution of that relationship on this particular front. It's a good relationship in this particular effort."
Leung said the cooperation started with the success of the joint teamwork Oracle and Sun did in developing TopLink Essentials, which is an open source project the two companies worked on, using the code base from the Oracle TopLink product. The TopLink code has now been donated to Eclipse and is currently in incubation as the EclipseLink project.
Sun and Oracle have been partnering on TopLink Essentials since the beginning of work on Java EE 5, Pelegri-Llopart explained. TopLink Essentials, was used in the persistence API for the first two versions of GlassFish, the open source version of Java Platform Enterprise Edition (Java EE) 5 application server, he said.
"What we announced today is that we're using EclipseLink for the third version of GlassFish V.3, which is based on the new standard Java EE6, which includes Java Persistence API 2," he said. "So in a sense we are upgrading from TopLink Essentials, which was a subset of TopLink, to its bigger brother, which is EclipseLink based on the same general code base. It just has more features and it's now hosted at Eclipse."
EclipseLink, which provides caching for high volume transactions in enterprise applications, will be included in GlassFish V.3 when it is released next year, Pelegri-Llopart said.
Sun's selection of EclipseLink was also driven by GlassFish user demand, he said.
"TopLink Essentials was very good for some applications, but as they start pushing the boundaries for performance people ask to have the rest of the features that are in the Oracle version of TopLink," he said. "What Oracle and Sun realized was there was a real demand for open source high quality implementation. What we want to provide with GlassFish V.3 is a high performance, top quality implementation and that's what this relationship with Oracle and Eclipse is going to provide."