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
JSR Review Ballot
Ballot duration: 2004-04-20 to: 2004-05-03

These are the final results of the JSR Review Ballot for JSR #243. The Executive Committee for SE/EE has approved this ballot.

Votes

SE/EE

Apache Software Foundation

Apple Computer, Inc.

BEA Systems

Borland Software Corporation

Caldera Systems

Fujitsu Limited

Hewlett-Packard

IBM

Lea, Doug

Macromedia, Inc.

Monson-Haefel, Richard

Nokia Networks

Oracle

Progress Software

SAP SE

Sun Microsystems, Inc.

Icon Legend
Yes
No
Abstain
Not voted

View Vote Log

SE/EE

On 2004-04-30 Sun Microsystems, Inc. voted Yes with the following comment:
This is in response to some of the comments on JSR 243 "JDO 2.0".

If JDO did not exist, it might be a worthy topic for debate as to
whether the Java community should invest in this area.  I can see
pros and cons on both sides.  But JDO does exist, and it has a loyal
user community who want to see it continued and extended.  Sun, as
specification lead for JDO, is responding to what we perceive as
legitimate community demand for evolving JDO.

Sun believes that there is space for both JDO and EJB.  I hope the
expert groups can cooperate to minimize any unnecessary differences
in areas where they overlap.  Whether or not JDO should be included in
J2EE is an issue for a future J2EE expert group to debate.

Given that JDO exists and has attracted significant interest from
the Java community, I think it is appropriate to allow it to continue
to evolve, based on the feedback and requirements from its users.

                                                     - Graham

------------------------------------------------------------------------------
On 2004-04-20 Lea, Doug voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-04-20 SAP SE voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-04-20 Monson-Haefel, Richard voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-04-22 Progress Software voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-04-26 Nokia Networks voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-04-26 BEA Systems voted No with the following comment:
JDO is one of many different persistence solutions in server-side Java today. With J2EE 1.5 emphasis on simplification and ease of use, we don't see how having another release of JDO, whose market acceptance is essentially constrained to use with object databases, can be explained in conjunction to similar enhancements being made in the EJB3 expert group. We are also concerned about taking JDO into new areas such as disconnected data set support until we better understand how ball of these solutions fit together. Unless the submitters can explain how all of this fits together, we believe the Java community would be better served with fewer apparently competing alternatives.
------------------------------------------------------------------------------
On 2004-04-26 Apache Software Foundation voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-04-30 Fujitsu Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-04-30 IBM voted No with the following comment:
This JSR proposes to develop extensions to JDO that apparently overlap with existing Java technologies and with other JSRs that are already in-progress.  In a context where the Java community is working to simplify J2EE, it is undesirable to produce multiple overlapping ways of programming the same function.
------------------------------------------------------------------------------
On 2004-04-30 Macromedia, Inc. voted Yes with the following comment:
While undesirable overlap does appear to exist between JDO and other JSRs, the feedback we have long heard on this particular subject is that Java application developers prefer to adjudicate the overlap themselves rather than have the decision enforced for them by platform vendors. The community appears to desire a choice between persistence technologies even at the expense of the additional platform complexity and fragmentation that the overlaps between those technologies can cause. We consider our vote in favor of this JSR to reflect not an architectural platform aesthetic, but instead to reflect the more practical majority sentiment long and loudly expressed by customers and others in the community.
------------------------------------------------------------------------------
On 2004-05-02 Caldera Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-05-03 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-05-03 Apple Computer, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-05-03 Oracle voted No with the following comment:
JDO 2.0 overlaps with the work being done by the EJB 3.0 expert group to provide a lightweight persistence model. Having 2 specifications address the same problem space with different APIs, persistence and transaction semantics, mapping definitions and query mechanisms does not contribute to the effort of simplifying J2EE and making it easier to use. The direction of lightweight persistence being taken by the EJB 3.0 group will have tremendous appeal to mainstream enterprise Java developers, even those who are critical of the current Entity Bean model. Given the evolution of EJB 3.0 persistence, another independent standard for persistence is unnecessary and will add confusion to those looking to adopt J2EE technology.

------------------------------------------------------------------------------