techno.blog("Dion")

The official announcement will come out of Sun on Monday, but the cat is out of the bag.

Firstly lets look at the facts:

• A new spec/RI/TCK is being created UNDER the JSR-220 (EJB3) umbrella
• 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:

1. 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.
2. 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
3. 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!