How the politics of thinking about Java as a platform, versus Java as a language, will be good for us Consilidating Spring Config with Groovy
Sep 25

JDO and EJB join forces: The cat is out of the bag

EJB, JDO, Java, Tech Add comments

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!

5 Responses to “JDO and EJB join forces: The cat is out of the bag”

  1. Jason Carreira Says:

    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?

    This is what worries me about it being based on the current EJB 3.0 work and living in the EJB JSR.

  2. Dion Says:

    Gabriel -

    JDBC isn’t hidden away. There are provisions for this via:

    a) You can grab a JDBC connection within the same TX context
    b) You can use SQL as the query language

    Dion

  3. Carlos Sanchez's Weblog Says:

    JDO and EJB join forces

    Dion wrote an interesting entry about the joining of JDO and EJB . A new spec is being created to provide an unified persistence API for both standard and enterprise java editions using POJ Os.

  4. Cedric Says:

    The annotations are definitely staying.

    As for the pluggable persistence manager, we’ve had this since WLS 5.0 (!) but we phased it out because, simply put, nobody ever used it, so I question your assertion that a lot of people want that…


    Cedric

  5. Dion Says:

    Cedric -

    This surprises me, as it hasn’t been my experience.

    I have been on many projects where we really wanted to change the persistence manager.

    For example, being stuck with WebSphere and wanting something better than their CMP.

    What normally happened was one of two things:

    - Shoot, we are stuck with their damn CMP (since management has mandatted CMP)
    - We can get away from this… let’s use JDO where we can CHOOSE the damn vendor depending on our needs (or end up using Hibernate)

    Since everyone will be moving to this ONE persistence API, I think it makes OBVIOUS sense to make it so you can plugin the vendor that you wish!

    However, I totally understand the app server vendors don’t want this :)

    Dion

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: What is the number before 3? (just put in the digit)