EJB JDO, what's going on

I've read with interest the discussion on the go between the JDO camp and EJB camp.

If you're not familiar with it, I'll give you a brief background.

EJB, more specifically "entity beans" is a persistence framework. JDO (java data objects) is also a persistence framework. The Entity beans framework is part of the broader EJB spec, currently in version 3.0. JDO is a "stand alone" specification in a similar vein to EJB in that Sun publishes the specification and a vendor then implements that specification and sells it on the market. JDO can be used in a desktop app, a web app or in an application server. Entity beans requires an application server to work and comes with significant overhead because of this.

I have used JDO extensively and have recently started looking at EJB in its version 2 guise. To be honest, the learning curve for Entity Beans is huge! It would take a developer twice if not three times as long to be useful under Entity beans than under JDO. I know because I was new to JDO at one stage and can remember how long it took me to learn. The developer would need to learn a lot of not specificaly persistence related stuff like session beans and local/remote interfaces.

There have been a number of discussions on the pros and cons of JDO against EJB. What makes the discussion even more interesting is that the latest EJB 3.0 spec, from what I've read, is unashamedly Hibernate! There are a number of conspiracy theories floating around as to why the EJB expert group went that way. The plot thickens when you consider that the JDO 2.0 specification is still in the process of being ratified - it has been rejected once already.

One of the loudest shouts in the community has been "We don't want two persistence frameworks!". My response to that is "why not?". It gives the user choice, it increases quality via increasing competition, it promotes flexibility. I say bring on alternatives.

This is the rationale behind the push on EJB 3.0. It seems that somehow this specification has won the day and that JDO has been abandoned. The primary reason for this I think is that because of the fact that Entity beans require an application server to work, the large vendors, Oracle, BEA, IBM, JBoss (who own hibernate btw), have supported the EJB specification because that way they protect their market.

To utilise JDO you do not need a heavyweight, complex and expensive application server.

The other apparent reason for the support of hibernate via EJB 3.0 entity beans is that hibernate uses standard sql as its query language. This not only locks the user into the underlying database but apparently affords the developer a seamless cross-over. I do not see how this can be seamless when the developer has to learn about all the overhead that comes with running on an application server.

I had to learn the JDO QL (JDO Query Language), and the syntax is a lot cleaner than SQL. JDOQL is far closer to object space than SQL is. It is just a more obvious and better fit when it comes to the object space. The key here is that it is far easier for an OO programmer to learn JDOQL than it is for an OO programmer to learn SQL. Which is why I do not buy the "they'll have to learn a new query language" rhetoric.

Furthermore, there is no reason why you can't use JDO with an application server. Again, surprise surprise, you have choice.

Reading various articles on the subject might indicate that JDO is dead, well, I was pleasantly surprised to note that the final round of voting on the JDO 2 spec is imminent. See jcp 243.
I'm holding thumbs for its adoption.

It probably won't be ratified however; based on the voting up till now a betting man would not put money on it.

Ultimately, I think that Apache opinion is correct and the most democratic and "broad based". They have always maintained "Let The Market Decide!". The specification is good enough, the implementations are of sufficient quality that the computing industry will use it. Proof of this is that a number of companies have already implemented the JDO 2.0 specification without it's ratification! JDO fulfills important requirements quite efficiently. In my work place we have used it for two web applications so far, and have seen no reason to go the Application server route.

Let's hear it one more time, Let the Market Decide!

btw, if you have an opinion, then tell me what you think...