This is great news. After the debacle of the first round of voting, today we had the revote.
Many expected that the initial vote was the death of JDO, but this have thankfully been proven to be premature and false.
There was a large outcry from those inside the JDO community, and even those that are external to it. From talking to the EC after the vote, it was apparant that the "NO" voters were not actually voting against JDO, rather against the timing (around xmas), not knowing about how it fits with the JSR 220 persistence spec, and the process in general.
Kudos to the JCP EC, who listened to the community, and then made their decision.
The different thoughts are shown in the comments:
Regarding the letter, and the JSR 220 agreement
Intel: voted Yes
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.
SAP: voted Yes
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.
Regarding the process
Intel: voted Yes
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.
Abstainers
Last time around, I felt that some of the EC should have voted 'Abstain' rather than 'No'. This time, the abstains have come in as veiled No votes, and strongly try to put across the message of "I guess we will allow the tiny JDO community continue while we take on the world" :)
JBoss: Abstained
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.
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.
Oracle: Abstained
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.
Favourites
Of the votes, I think my favourite has to be:
Apache Software Foundation: voted Yes
Let a thousand flowers bloom :)
BEA: voted Yes
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.
Vote Results
Yes (12)
Apache
BEA
Borland
Doug Lea
Fujitsu
Google
HP
IONA
Intel
Nortel
SAP
Sun
Abstain (3)
JBoss
IBM
Oracle
NOTE: For some reason Apple didn't vote :)
Time to move on
Now it is time to move on. JDO 2 can continue its great work. We can work with the EJB team to help out there too, and everyone is a winner.
See the results of the vote
Previous Topic
