eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The results are in, and a controversial vote regarding the future of a Java persistence standard has been overturned in a reconsideration ballot in the Java Community Process.
Initially, the JCP executive committee in January voted against the Java Data Objects 2.0 specification, also known as Java Specification Request 243 (JSR-243), in a public review ballot. However, with all the votes in on Monday for the reconsideration ballot, the specification has been approved.
The initial vote caused a storm of controversy among Java developers. It prompted a petition calling on developers to join in renouncing the vote and more than 1,000 did.
The initial vote was 10 for the specification and five against, with one abstention.
For the reconsideration ballot, the results were 12 for the specification, three abstentions and one company that did not vote. The Apache Software Foundation; Fujitsu Ltd.; Iona Technologies plc; Nortel Networks; Google Inc.; Intel Corp.; BEA Systems Inc.; Hewlett-Packard Co.; SAP AG; Borland Software Corp.; Doug Lea, a professor at the State University of New York at Oswego; and Sun Microsystems Inc. voted for the specification. Oracle Corp., JBoss Inc. and IBM abstained, and Apple Computer Inc. did not vote.
In the initial vote, companies such as HP, IBM, Intel, Iona, JBoss, Oracle, SAP and BEA voted against the specification, while the Apache Software Foundation, Apple, Borland and Sun voted for the specification, and Google abstained.
In the reconsideration ballot BEA added the following comment: “After further review, BEA has concluded that there is a vibrant JDO community which needs this specification, regardless of whether we are successful in achieving an overarching persistence strategy.”
Sun, which 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, did not offer comment with its yes vote.
Intel, which initially voted against the specification, said with its reconsideration vote: “The extra time for review has demonstrated that the JSR 243 Public Draft is consistent with the letter from the Spec Leads so there is no problem there in any case. In similar situations in the future, it would be better to use the usual process of initiating a new JSR rather than a letter from Spec Leads. That would provide more transparency and involvement of the community.”
According to the JSR description of the specification, JDO provides a database abstraction that allows API access to data stores without detailed knowledge of the underlying data store API. And the technology has been used to develop implementations for file storage and relational and object databases.
“At SolarMetric, we are thrilled about the result of this vote for our 325-plus customers,” said Neelan Choksi, president of SolarMetric Inc., an Austin, Texas, developer of JDO-based solutions such as Kodo. “For them, this further affirms their decision to go with Kodo and the JDO standard as a solution to one of the more time-consuming problems in enterprise Java. According to customer interviews, persistence represents on average 20 to 30 percent of total coding time in a normal enterprise development project. When using Kodo, their numbers drop to around 5 percent. This means developers can focus less on infrastructure code and more on solving domain problems for their specific industry.”
Choksi said the goals of JDO 2 have been met, including maintaining JDO 1 compatibility, standardizing mapping to relational databases, supporting SQL as a query language, and improving multitier development and usability, as well as better object modeling, richer queries and more vendor support.