The Java Community Process(SM) Program - JSRs: Java Specification Requests

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy
JSR #243
Java^TM Data Objects 2.0 - An Extension to the JDO specification
Public Review Ballot
Ballot duration: 2005-01-11 to: 2005-01-18
These are the final results of the Public Review Ballot for JSR #243. The Executive Committee for SE/EE has not approved this ballot.
Votes

SE/EE
Apache Software Foundation
Apple Computer, Inc.
BEA Systems
Borland Software Corporation
Fujitsu Limited
Google Inc.
Hewlett-Packard
IBM
Intel Corp.
Lea, Doug
Nortel
Oracle
Progress Software
Red Hat
SAP SE
Sun Microsystems, Inc.
Icon Legend
Yes
No
Abstain
Not voted
View Vote Log

SE/EE
On 2005-01-18 Apache Software Foundation voted Yes with the following comment:
Apache reconfirms it's "yes" vote noting that the letter stated only that   "the scope of JSR-243 will include maintenance to JDO 1.0.1 and enhancements to JDOQL", conditions which have been satisfied.

We agree that having multiple persistence technologies in Java could be confusing to the market.  However, we believe that this is something for the market to decide, rather than one company.

Regarding concerns of alignment, Apache supports there being an alignment of the JDO and EJB persistence specifications, but feel that the proper way to do such a thing is to form a third, independent expert group focused on persistence only, taking input from existing stakeholders like the JDO persistence framework, and the EJB component framework.

Let a thousand flowers bloom.  Let the market decide.
------------------------------------------------------------------------------
On 2005-01-18 Hewlett-Packard voted No with the following comment:
HP is changing its vote to NO after reviewing the concerns expressed by other EC members.
------------------------------------------------------------------------------
On 2005-01-18 Google Inc. voted Abstain with the following comment:
In light of the open letter to the Java Community from Linda de Michel and Craig Russell (http://java.sun.com/j2ee/letter/persistence.html), we believe that the interests of the J2EE platform are best served by the persistence work currently being performed under the auspices of JSR 220. We are worried that the JSR 243 draft in its current form does not address these intents and risks to further fracture the J2EE community.
------------------------------------------------------------------------------
On 2005-01-18 Progress Software voted No with the following comment:
Sun's letter that JSR 243 would include maintenance of JDO 1.0.1 and enhancement of JDOQL doesn't seem to be addressed in the Public Draft.  Some statements in this version's draft actually appear to belie Sun's email: "Metadata annotations for persistence are being developed in JSR 220. When that specification is final, JDO implementations might support those annotations instead of requiring xmlmetadata. An update to the JDO specification to standardize the annotations is deferred until then."  We are concerned about the confusion between the two differing statements of goals.
------------------------------------------------------------------------------
On 2005-01-17 Red Hat voted No with the following comment:
In September 2004, the JSR 220 and JSR 243 spec leads issued a public letter to the Java Technology Community announcing a joint effort to get a unified specification for Java persistence (http://java.sun.com/j2ee/letter/persistence.html).

The public letter stated that JDO 2.0 would essentially be a maintenance release of JDO 1.0.1 and enhancements to JDOQL and, more importantly, that they would include migration paths to JSR 220 through JDOQL "that would work with the new POJO persistence model so those with a preference for JDO query style can leverage the new common persistence API".  

It is our opinion that JDO 2.0 is much more than a maintenance release and that this will confuse the JCP community further as JSR 220 and JSR 243 were supposed to join forces.

We believe that JDO 2.0 should start focusing on unifying the API presented in the early draft of JSR 220, to which they can contribute since experts from JSR 243 were invited and now sit on the JSR 220 committee.

------------------------------------------------------------------------------
On 2005-01-18 Oracle voted No with the following comment:
We are concerned that the JDO 2.0 draft produced by JSR 243 does not follow the stated direction that Sun indicated in its open letter of Sept 2004 that "the scope of JSR-243 will include maintenance to JDO 1.0.1 and enhancements to JDOQL". We feel that the duplication that JSR 243 continues to introduce creates confusion in the persistence community and is counter-productive to J2EE.

------------------------------------------------------------------------------
On 2005-01-18 SAP SE voted No with the following comment:
SAP's understanding was that based on the open letter which had previously been published by both Spec Leads, there would be a strong alignment between both JDO and EJB persistence models. We are concerned with the timing of the JDO public release - prior to the EJB public release - as well as regarding the current scope of JDO which does not seem to have followed the objectives that were stated in the previous announcement. 
------------------------------------------------------------------------------
On 2005-01-17 Apple Computer, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2005-01-18 IBM voted No with the following comment:
The public review draft has done little to address the concerns we originally expressed in the JSR Approval ballot regarding the overlaps between JDO's proposed new capabilities and other similar Java technologies. 
------------------------------------------------------------------------------
On 2005-01-18 BEA Systems voted No with the following comment:
BEA shares the concerns voiced by Oracle, SAP, and others that the JDO 2.0 draft produced by JSR 243 does not follow the stated direction that Sun indicated in its open letter of Sept 2004. As a result, the duplication that JSR 243 continues to introduce perpetuates the existing confusion in the persistence community.
------------------------------------------------------------------------------
On 2005-01-18 Nortel voted No with the following comment:
Our understanding is that JSR 243 would follow the approach and policy described in (http://java.sun.com/j2ee/letter/persistence.html).in issued by the JSR 220 and JSR 243 spec leads in September 2004. 

We believe that this joint effort to get a unified specification for Java persistence is the right approach, and support it.

The letter stated that JDO 2.0 would essentially be a maintenance release of JDO 1.0.1 and enhancements to JDOQL and, would include migration paths to JSR 220 through JDOQL that would work with the new POJO persistence model.  
 
There is significant concern that JSR 243 is becoming much more than a maintenance release, and is not fulling aligning to the stated objectives.
 
We would like to see the approach to JSR 243 reviewed, with the aim of achieving much stronger alignment and support for a single persistancy model via JSR 220. JSR 243 must be restricted to minimal changes toi the existing JDO for maintenance purposes only.
------------------------------------------------------------------------------
On 2005-01-18 Borland Software Corporation voted Yes with the following comment:
The Java community can only benefit from offering a broader choice for our customers when it comes to a data persistence model.

------------------------------------------------------------------------------
On 2005-01-18 Sun Microsystems, Inc. voted Yes with the following comment:
For historic reasons, the Java community has evolved both the
JDO and the EJB persistence technologies. Each technology has
its own passionate advocates.

There is general agreement that having two similar persistence 
technologies is undesirable and that the community should converge
on the POJO persistence model as was described in the open letter
earlier this year.  This convergence is proceeding and on track.

However, as described in the letter to the community, the plan was to 
allow evolution of JDO to meet the near term needs of the JDO community, 
who seek an orderly evolution, not an abrupt end-of-life.  JDO 2.0 is 
significantly scaled back from its original plans, and now delivers 
minor improvements to JDO in support of the JDO community.

Separately, there continues to be excellent progress in the JSR-220
(EJB 3.0) expert group on the definition of the new persistence API
for Java.  Several JDO members have been added to the expert group
and the entire group is cooperating to produce a new Java persistence 
specification.  An Early Draft Review has been made available with 
overwhelmingly positive feedback.  And there is no doubt that the
shared focus going forward is this new POJO persistence API.

Sun has no particular axe to grind here: we would like to see rapid
convergence as much as anyone!  But as spec lead for JDO, Sun has
no desire to abandon or disenfranchise the JDO community.  We would
therefore respectfully suggest that it is appropriate to allow some
evolution of JDO to meet the needs of the JDO community, while still
treating convergence of EJB and JDO as the primary near-term goal.

------------------------------------------------------------------------------
On 2005-01-18 Fujitsu Limited voted No with the following comment:
We believe the relation between EJB should be clarified. 
------------------------------------------------------------------------------
On 2005-01-18 Intel Corp. voted No with the following comment:
We agree with the concerns other EC members have raised in consideration of this ballot.  It would be better to take the time needed to ensure changes in the JDO spec fit in with a longer range architecture for persistance.
------------------------------------------------------------------------------
On 2005-01-14 Lea, Doug voted Yes with no comment.
------------------------------------------------------------------------------