The passing of this ballot means that the JDO 2 expert group has received approval to continue with work on JSR243, including delivery of a Reference Implementation and a Technology Compatibility Kit. Existing JDO implementations will upgrade to JDO 2 and JDO users will have a temporary upgrade path. For those of you that want to read about the spec before posting about it, you can get a copy of it at http://jcp.org/aboutJava/communityprocess/pr/jsr243/index2.html.
Interestingly, very little has technically changed with the new draft submission. What resulted in the sway was a reclarification of the intention to "merge" into the EJB 3 persistence API, intense lobbying from various people in the community to the JCP EC committee, and a brief new preface in the new JDO draft which states that JDO 2 intended to meet the immediate needs of the JDO community and cannot exlicitly refer to EJB 3 since JSR 220 (EJB 3) isn't final yet, but that work has been done to make JDO QL work with EJB 3.
In the recent ballot, Sun, Google, Doug Lea, IONA, HP, Borland, Fujitsu voted to continue JDO, with no comments posted.
BEA voted Yes concluding that:
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. As a result, I see no reason to hold this community hostage to a goal that may or may not be achieved.Intel voted yes stating:
An agreement between the Spec Leads of 2 Expert Groups is not binding on the Executive Committee. That said, 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.Apache Software Foundation voted Yes saying "Let a thousand flowers bloom :)", a reference to their previous ballot vote where Apache said "Let the market decide."
Nortel voted yes and mentioned they "support the JDO Technology and its ongoing use."
SAP voted yes indicating that:
SAP thanks the JSR 220 and JSR 243 Spec Leads for the additional clarifications that were provided for this reconsideration ballot. We are satisfied with the clarifications regarding the future roadmap of EJB 3, JDO 2 and the new J2SE persistence model that is being developed as part of JSR 220 and therefore do not see an impediment for JDO 2 to proceed. Given that JSR 220 has the challenging goal to deliver an overarching persistence strategy for Java, it is important that the interests of all existing persistence communities, including JDO, are equally represented in this Expert Group.Among the companies most vocallly opposed during the previous ballot, IBM, Oracle and JBoss voted to abstain this time, IBM abstained with no comment, and Oracle abstaining with the statement:
Oracle's primary concern has been partially addressed with the FAQ published by Sun reiterating that JSR 220 is the intended standard Java persistence API moving forward. Given the clear direction set by Sun on this issue, we will not object to the evolution of the specification to serve the existing JDO community. It is vital that the persistence work in JSR 220/EJB 3.0 for the mainstream J2EE community not be disrupted. EGB 3.0 is making excellent progress as part of the umbrella J2EE 5.0 specification and has been well received.JBoss, which in 2003 supported JDO, grudgingly abstained with the comment:
Since this newly proposed specification is essentially identical to the one proposed during the Public Review Ballot vote, we would see no reason to change our vote, hence our previous comment remains.Due to similarities between JDO and EJB, there should be a fairly straight forward migration path in the future. "At the end of the day, people who use JDO 2 and people who use EJB 3 will have much more in common," said Patrick Linskey, SolarMetric’s CTO and active participant on both specification teams. "Rather than splitting the community in two, vendors like SolarMetric who will provide support for both JDO 2 and EJB 3 will ensure no member of the Java community is disenfranchised."
However, while this vote is fundamentally a NO vote, we cast it as an ABSTAIN to acknowledge Sun's role in trying to clarify the situation through their FAQ, and most specifically the central role of persistence in the JSR-220 specification and in the Java platform as a whole: "The new persistence API as defined by JSR 220 will be the standard Java persistence API going forward.".
This JSR-243/JSR-220 discussion, initiated by some JSR-243 proponents, has only brought disruption on the JSR-220 side and no sign of flexibility on the JSR-243 side. This could give the feeling of a coup to slow down the JSR-220 EG. The J2EE/EJB specification set represents the significant part of today's Java ecosystem. Hence, in order to remain competitive, it is critical to make sure these specifications don't get disrupted.
Although the expectation is that JDO will not be developed beyond minor maintenance releases and a 2.1 draft that clarifies EJB 3 integration, the new JDO draft concludes that "Future revisions of the JDO specification will be done as necessary to reflect the needs of the Java Community".