Discussions

General J2EE: Let JDO continue after 2.0 outside of JCP

  1. Let JDO continue after 2.0 outside of JCP (1 messages)

    Just went to Javapolis last week and I went too see the JDO 2.0 & EJB 3.0 sessions. I really like the stuff in JDO 2.0.
    The information about the new common persistence API in EJB3.0 worried me: The API is is the old EJB entity API (but now greatly simplified through annotations) with EJBQL greatly expanded (basically almost the same as SQL). So basically they are not restarting from scratch but are trying to fix the old entity beans (in such a way that the old entity beans still work) by probably switching the underlying implementation (but not the API!) to something very close to Hibernate with some JDO stuff thrown in, and make it look simple through annotations.

    It is totally focussed on OR mapping as is clear from the query language. No thought was given to querying non-relational data stores. From the talk it was also clear that the expert group had not thought for one second yet how this would work outside of a EJB container.

    From the point of a JDO user this seems like a regression rather then a progression. I doubt also that the JDO members in the expert group have a lot to say. they are probably squashed by the big EJB server vendors and are there more for political correctness to give the outside world the illusion that this new api really is a common effort.

    I don't see the need for this new persistence API: JDO does everything and more that this new API will do:
    - it runs perfectly standalone
    - you can easily use it in a EJB server: either by using it like you would standalone (programmatic transactions) or by letting the container manage the transactions via the JCA API.
    - easily integrates with Spring so that Spring can declaratively manages the local JDO transactions. This is not possible with EJB since there global JTA transactions are used! Frankly I care much more about Spring then EJB because I think this is the future not EJB (not even EJB3.0)
    - let's me query non-relational data stores using the same API.

    One can question if sacrificing JDO to save entity beans is the right way to go. When Rod Johson in his the talk 'J2EE without EJB' at Javapolis asked how many people were still using entity beans only a few people (out of maybe 300 persons) raised their hands; so clearly people have left entity beans behind and either switched back to JDBC or switched to Hibernate or JDO. So why give up a good working thing like JDO which is actually being used to try to fix a broken thing like entity beans that nobody uses anymore. the answer is of course: politics. The EJB vendors recognized that entity beans were crap, that JDO works well but rather than give up entity beans and just stick with session beans (the only thing they should be doing anyway since the task of an app server is not persistence but transaction coordination), like little children they still wanted to be the winners and just hijacked JDO via the JCP by deciding that JDO 2.0 would the end of JDO and that they were the future of persistence and that they now finally after have tried many times already to get it right would now get it right and everybody should migrate to their API.

    The right to do would have been to drop entity beans and adopt JDO.

    I really feel that this has shown that the JCP is not the unbiased, vendor politics-free process we hoped it would be. I really would like to see JDO continue beyond JDO 2.0 and maybe the best place for this is not the JCP but outside of it. Maybe the best place for this would be in the form of an open source project. this would allow to experiment with new features before setting them in stone in the spec and avoid design by committee. The new Apache JDO project for the reference implementation would be a good place to start.

    Maybe we should start a poll on the server side about this? What do you (JDO) guys think about this?
  2. Steven,

    Some vendors (Oracle and Hibernate being the most vocal) feel strongly that JDO is not the right API for their customers. Some JDO vendors feel that EJB3 is the wrong way to go. Some look at the market opportunity created by aligning the specifications closely enough so that one implementation can service both APIs with minimal changes, and are excited about that.

    The natural question from your suggestion, though, is not whether JDO will continue outside the JCP -- it will, as there will be people who prefer JDO to EJB3, regardless of how good or bad EJB3 ends up being. The simple fact that developers will have had more than a year to build projects with JDO 2.0, let alone the three years since JDO 1.0 came out, means that there will be support work for JDO engineers for years to come. The question is, is there any value in a Java specification that exists outside the scope of the JCP?

    Fundamentally the JCP is a marketing organization. It exists to give the market and developer community guidance on what technologies to adopt, in what ways. The most important function is defining the standard profiles of J2SE/J2EE/J2ME. JDO exists outside of all of these already. EJB exists as part of J2EE. So the question is, could we swap EJB out of J2EE and replace it with JDO? While it's theoretically possible, Sun has never (as far as I can recall) entirely dropped an API. The only reasonable approach would be for both to be included in J2EE, and as you say there is significant political pressure to avoid this, as it would be a bad marketing move, in most people's eyes -- "why are there two persistence 'standards'?"

    Wes