eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
A recent vote regarding the data persistence model for Java is showing more fraying in the Java community fabric.
The executive committee (EC) of the Java Community Process last month voted against the Java Data Objects 2.0 specification, also known as Java Specification Request 243 (JSR-243), in a public review ballot. That vote spawned a rash of responses on Java-related sites, including a petition to have the vote reconsidered.
The JDOCentral.com Web site has an online petition decrying the EC vote and calling for developers to join their campaign. So far nearly 1,000 have.
The vote came down to 10 against the JDO 2.0 specification, five for it and one abstention. Companies such as Hewlett-Packard Co., IBM, Intel Corp., Iona Technologies plc., JBoss Inc., Oracle Corp., SAP AG and BEA Systems Inc. voted against the specification, while the Apache Software Foundation, Apple Computer Inc., Borland Software Corp. and Sun Microsystems Inc. voted for the specification. Google Inc. abstained.
Some observers say the issue is rife with politics.
However, Sun last fall sent an open letter to the Java community calling for a new, single data persistence model for Java that would combine the core focus of two key specifications and give the Java community a single target to work toward.
In the letter, Linda DeMichiel and Craig Russell, chairs of the Enterprise JavaBeans (EJB) 3.0 (JSR-220) and JDO 2.0 specifications, respectively, said: “For years, the Enterprise JavaBeans and Java Data Objects 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.”
However, the JDOCentral petition says: “If JDO 2.0, an extension of the existing JDO 1.0 standard, is not approved, it will cause significant damage to developers and vendors that rely on JDO, it will create irreparable damage to the reputation of the Java Community Process, and it will hurt the Java developer community at large.”
Moreover, “Not accepting JDO 2.0 and referring developers to a future EJB standard, which most likely will not be available for some time, leaves a significant void in the market for a robust Java persistence standard, causing it to be filled by proprietary products and solutions,” the petition said.
The petition also points out that JDO 1.0 is a successful standard, the JCP passed the original JSR-243, vendors and developers have already adopted many of the useful JDO 2.0 extensions, and JDO is not positioned against any EJB specification.
Next Page: Weblog post full of frustration.
Page 2
Meanwhile, an anonymous post to the Web log of Richard Monson-Haefel, an analyst for the Burton Group Inc. and enterprise Java expert, spelled out the frustration some developers are feeling regarding the vote.
“The implications of a negative vote are much more far reaching,” the anonymous post said. “Can any company trust the JCP to not screw them? Numerous companies, like mine, have invested millions of $s into JDO because the JCP voted it as a standard. My political capital in my company is currently shot because of this negative vote.
“I am incredibly frustrated because the JCP implied that JDO would be a supported standard. In fact, the JCP approved the Early Release Draft of JDO 2 right before my company made a decision to purchase and I was happy that it passed. As such I approved the purchase of JDO technologies for my company. Then magically, a letter from Sun suddenly comes out changing the charter of both JDO 2 and EJB 3. Now, the JCP can take a minor update to an existing, popular standard and simply get rid of it because it is not in the best interest of biased vendors like Oracle and JBoss.
“Whats worse is that the features in the update were all driven from end user requests. If EJB 3 was here today and covered all of the features that were in JDO 2, that would be understandable. However, EJB 3 as it currently stands is a shell of a standard when compared to JDO 2 and it likely wont be available till 2006.”
Further, the anonymous poster said: “Microsoft shows you what the world would be like if there was only one standard for each technology. Why is the JCP insisting that there should only be one standard for persistence?”
The anonymous poster ended the post saying dissatisfaction with the Java community could lead developers to Microsoft. “If the Reconsideration Ballot is not approved for JDO 2 or if JDO 2 is changed dramatically to meet the needs of biased vendors, this may be the straw that breaks my back. Java may very well be dead to me and where financially viable, I will start moving my development to .Net.”
Meanwhile, others said they expect the reconsideration vote to right the situation.
Eric Newcomer, chief technology officer at Iona, said, “The controversy arose when the JDO committee submitted a specification draft that did not appear to align with the committees previously stated goals. Some might have interpreted this as an attempt by the committee to go beyond its charter, since the original charter stipulated the result to be a maintenance release, not a major functionality upgrade, as the draft appeared to be.”
And in some respects the confusion appears to have been interpreted as a POJO versus EJB situation, “but to me it seems like people were reading this into the situation based on their previous disposition toward one or the other,” Newcomer said.
Next Page: A procedural response.
Page 3
Newcomer added that Iona had made a negative vote more as a procedural response. “The nay vote on JSR-243 was done to cause Sun to decide which set of goals the JSR was supposed to be evaluated by,” he said, noting that Sun was the specification lead on the JSR. “Now that the situation has been clarified we have voted in favor.”
Rod Johnson, a London-based enterprise Java architect, J2EE (Java 2 Enterprise Edition) consultant and author, expressed his dismay over the situation.
“I think the confusion [and politics] around JDO/JSR-220 is unfortunate for the cause of O/R [object-relational] mapping on the Java platform as a whole,” Johnson said. “Its good to see that the EJB expert group finally recognizes the value of POJO persistence, and that persistence should be separate from the EJB container. So theres a degree of convergence.
“However, there already was a POJO persistence specification—JDO—and I think it would have been better to work toward improving that to satisfy all users, rather than to begin a new effort. A lot of excellent work has been done on JDO 2.0, which is a big step forward and looks more mature than JSR-220. I think its in the interests of the Java community for JDO 2.0 to be ratified.”
“I hope the JCP executive committee reconsiders its no vote on JDO 2.0 in light of the nearly 1,000 developers supporting the JDOCentral.com petition,” said Rick Ross, president of Javalobby.org. “The real problem, however, is the wholesale failure of Java developers to join the JCP, vote in Executive Committee elections, and hold EC members accountable for their choice through the democratic processes built into the JCP charter. Only 221 of 755 eligible JCP members voted in the 2004 JCP EC election—resulting in a 29.3 percent voter turnout that is even worse than American presidential elections.
“[Each of] the 221 votes represent just one for every 13,500 Java developers, if we accept Suns estimate of 3 million Java developers. Its very difficult to regard these 221 votes a quorum that allows Java standards to be considered genuinely sanctioned by a community process. Id much prefer to see 10,000 or more developers chiming in to make choices that guide and bind the evolution of Java technology standards. Apathy in the democratic process leads to bad results. JDO 2.0 is in jeopardy largely because of apathy.”
Neelan Choksi, president of SolarMetric Inc., in Austin, Texas, said, “Since the vote was announced, the JCP EC, Sun and the EJB 3.0 and the JDO 2.0 expert groups have been doing the right things by communicating and working together to ensure that a positive vote takes place as soon as possible. I believe there will be a positive resolution to this issue.”
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.