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

UPDATED NOTE: Apple didn’t vote as the EC member was on vacation :)

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.

TheServerSide communities are now running on Tapestry on the front end, and Kodo JDO for the data access.

We had known for awhile that it was ready for a change, and it was an interesting experience choosing what we wanted to port TSS over too.

There are many great web frameworks, and data solutions, but we definitely ended up happy with what we got.

The port was done in record time, in no part thanks to having Howard Lewis Ship on the team. If you are ever doing a Tapestry project, you owe it to yourself to bring him in for a bit. Not only does he obviously know Tapestry inside and out, but he is just a top class developer which great ideas!

Looking at the before and after version of TheServerSide is very interesting. Now TSS has a great, component-based version which is easy to extend. Before, it was always a fight to change / add anything.

It also doesn’t hurt that the site is faster and more stable than ever before. Kodo JDO has been top notch on that scale, and it has the solid Tangosol Coherence under the scenes as the distributed cluster technology.

Although JDO 2 may not get voted through. It isn’t dead yet. All you have to do is look at the TSS thread to see how people feel about it.

I still have hope that some of the guys that voted ‘No’ (those who don’t have a real political motivation to kill JDO) will come around. I think there has been a mixup in the process, and people need to communicate better. It also didn’t help that this all happened over a winter holiday so, some people feel like they didn’t have the required time to feel like they could say ‘Yes’ (although I would prefer an abstain like Google).

I also think that RMH is wrong when he says:

I believe that the EJB 3.0 POJO persistence model will become pluggable so that you can choose your persistence provider separate from your J2EE vendor.

Take a look at the EJB 3 early draft. This is NOT in scope! The vendors claim that ‘users have not asked for this’ in EJB. I agree with RMH 100% that we SHOULD have a pluggable implementation of the persistence manager / entity manager / whatever it ends up being called in the final EJB 3. Without it we get the same lockin that we have now. JDO has allowed us the freedom to change implementations, and NOT be locked in like this, and it will be a sad day if we lose it. Sad enough to make some nice folks say ’screw it’ and pick up Ruby even more :)

These give a glimpse at the good and the bad side of the Java community.

On the ‘good’ side we have the AOP news. Here we have two communities coming together for the greater good of the overall community. There isn’t the politics, nor the egos of “my app is better than yours”. They got together and talked about how they could work together and end up with a merger which is going to change AOP forever.

On the ‘bad’ side we have the JDO 2.0 ballot news. Here we have politics getting in the way. There are JDO users who are desperate to get JDO 2.0 implementations into their hands. They need it to take care of their business. Take a look at the vendors who went against the spec, and those who are for it.

I was optimistic, yet worried at the same time, about the EJB 3 / JDO 2 news that came out. It appears that some people are using that news as a way to hold back the JDO 2 spec. A lot of people have spent a LOT of time on that work, and our users deserve it right now.

P.s. I really liked Aslak’s quote regarding the AOP merger:

Forking seems to be more common than merging in the OSS world. This is great news. I wish you good luck.

The Apache DB group voted on a new JDO proposal. The new proposal spells out a place for some serious JDO work to happen.

It has been brought together with leaders in the Apache, other open source, and JDO worlds:

Abe White, SolarMetric, JDO expert group member

Brian McCallister, OJB committer

Craig Russell, Sun, JDO Specification Lead

Dain Sundstrom, GlueCode, Geronimo committer

Erik Bengtson, JPOX committer

Geir Magnusson, GlueCode, Geronimo committer

Michael Bouschen, JDO expert group member

Michelle Caisse, Sun, JDO TCK developer

Patrick Linskey, SolarMetric, JDO expert group member

Victor Kirkebo, Sun, JDO TCK developer

There are six initial subprojects envisioned:

JDO 1.0 API

JDO 1.0 Reference Implementation

JDO 1.0 Technology Compatibility Kit

JDO 2.0 API

JDO 2.0 Technology Compatibility Kit

JDO 2.0 Geronimo integration

I witnessed a lot of good talk at ApacheCon, and I am happy to hear that it is coming to fruition. With these fine blokes behind it, I am hopeful for a top notch JDO implementation with an Apache brand.

OJB supports a JDO interface via a plugin to the JDO 1.0.X reference implementation (which is SCSL, non-commercial variant) so is basically useless right now. This same RI is part of the initial codebase for this project, so the OJB JDO 1.0.X interface can actually become useful =)

This new spec will be based on the persistence API from the EJB 3 early draft

The scope is for a persistence API for BOTH J2SE and J2EE (so it will work outside of a container)

JDO experts have been invited to join the EJB team to grow it from here

The final spec will be available in the same time frame as J2EE 5

The JDO 2.0 spec will continue. It will now add the ability to externalize JDO-QL so it can be used from the new persistence API

I am really hopeful with this situation. A lot of the folks on the JDO camp are NOT all about JDO… they just want a transparent persistence model that isn’t stuck in a container. Now it looks like this is going to happen, and the EJB folk are on board too. If this is done right then it will be a huge win for everyone.

Although I am really excited about the potential, the proof WILL be in the pudding, and I have a couple of concerns:

Where it lives

In my mind there were three options for placing a spec which holds a persistence API for J2SE and J2EE:

JDO: Since this spec kinda has that mandate already, it could have lived here. A reason for doing this would be that there are already users of this API. A reason for not doing this is that there are already users of this API.

EJB 3: It seems a little strange to have a spec that covers J2SE in an EJB spec umbrella, but they have done work on this themselves. I would argue that more work has been done with JDO 2, but hey, let’s move on

New JSR/Group: I know it would have taken more time to come up with a new JSR, but I would have ideally wanted this. A new group would have been formed and it would have set the tone to be a brand new collaboration. As it stands some people are skeptical that the JDO folk will be listened too. I am really hoping that everyone gets their say and that we get a great spec.

Pluggable Persistence

EJB specs have always talked about the idea of a Persistence Manager, and hinted that at some time this will be pluggable. JDO specs have had this notion from the beginning.

I *really* like the fact that JDO plays nice with the J2EE CA, so I can deploy whatever persistence manager I want by throwing a RAR at my application server. This seems like a no brainer on what it should be.

I want to be able to run WebLogic Server with IBM’s persistence manager. Well, I don’t really want that combination, but I want the flexibility.

From what I have heard on the grapevine, the new persistence API may not have the pluggable contract which really bugs me.

Why wouldn’t they define this? The only reason in my opinion is that application vendors don’t want this as they obviously want lock-in.

Please, please, please open up and allow the best persistence managers to fight it out in the market.

Finish on a positive note…

Overall I am really excited on this new bold move from Sun. Kudos to them for getting together and working out that this makes sense for the community. I really hope that in practice this works out and we get a great persistence API that everyone is happy with. My few worries above are only mentioned in the vein hope that people think about these things and we do the right thing.

Let’s get to work!

Update:

Jason has good comments:

Any idea if it’s still going to be dependent on 1.5 with annotations? And are those annotations going to be defined and jar’d in the j2ee.jar? Will I have to compile against the j2ee.jar or a vendor jar and either ship with the j2ee.jar or deploy in a container just to get the annotation classes?

I really hope that since this sub-spec is meant to target J2SE, that there is no need to ship j2ee.jar. Surely!

But back to the blog from Geir and Jeremy. The go through the problem at hand, and notice that we all want the same thing:

Give me a transparent persistence API

It looks like we can agree on that. So then the next question is how do we get to that path.

It seems like a no-brainer to me that we should use JDO 2.0 to get there, but I am of course biased. JDO shouldn’t only be in J2EE, it should be in J2SE in my opinion. You know, sometimes I want to access a data source WITHOUT being in an enterprise environment! I definitely want to do this without having to have an EJB container.

It is great to hear this from some of the Apache guys, and I look forward to us all coming together to work on the same problem. If we got in the same room we would find out that having blue eyes or brown eyes don’t matter. We both see.