Like the middle-aged father quoting rap lyrics, the JCP has apparently embraced Hibernate as the underlying persistence mechanism for EJB3 in an attempt to be hip, or at least relevant. The article seems strewn with misinformation: “as database vendors also, they probably prefer Hibernate to JDO because it uses the SQL syntax of the underlying RDBMSâwhich allows applications to be locked in to a specific database vendor”, and much of the article is based on the author’s reaction to Marc Fleury’s grandiose merketing statements. It’s also a tainted article in that the author has a horse in the race as a member of the JDO 2 expert group.
That being said, this decision, if true, is a curious one to say the least. The entire EJB3 proposal does smack of desperation – EJB have been so broadly panned in community discussion and even in print (“Bitter EJB”) that something needed to be done to keep them from fading into obscurity. In many ways, a radical departure was needed – lightweight containers and transparent persistence have taken so much mindshare that without an answer from the JCP, the only standards would be de facto ones (Hibernate, Spring, etc). JDO 2 has the promise of being up to the task of transparent persistence without requiring a full J2EE container, but apparently the two expert groups have chosen to be adversaries rather than allies. So they couldn’t use JDO – that would require the two groups to play nice. They didn’t want to make up a new standard – people would ignore it. Instead, they chose Hibernate, certainly helped by Gavin King’s presence in the EJB3 expert group (his work on Hibernate is to be applauded). In doing so, certainly they are hoping and praying that they can instantly capture mindshare by hitching themselves to the buzz-heavy Hibernate, and hoping to recapture all the current Hibernate users as EJB users.
It’s well-known that Gavin has technical beefs with JDO, but salvaging EJB is a far taller order than overcoming minor technical disagreements in the JDO spec. This decision is a dangerous one. Weaving a vendor’s proprietary technology into the heart of a J2EE spec throws too much power to one vendor – I wouldn’t put that trust in BEA, IBM, Pramati, etc. It is even more unstable when that vendor is the unpredictable JBoss group. To my knowledge, it would be a first – the first adoption of an independently developed framework as a part of a J2EE standard (although Groovy is trying as well). Let’s hope that, as Cameron suggests, they are merely pulling ideas from Hibernate rather than adopting it. Time will tell whether EJB3 emerges as a goofy 45 year fronting Ecko gear or a svelte technology borne of an extreme makeover gone right. EJB are in dire straits, only dramatic action can make them relevant again, but the wrong drama could lead to an epic power shift that nobody needs.
4 thoughts on “EJB3 to use Hibernate? Desperation and politics.”
The article you referenced is quite misleading. It seems to me that the EJB panel has endorsed the implementation of a “Hibernate-like” POJO approach. Perhaps for brevity or the lack of a better term (as yet) the approach has been dubbed “Hibernate”. Granted, since this approach may well be promulgated by the expert panel, it does benefit Hibernate and therefore JBoss, but simply because they get the glory and a kick ass head start. Small price to pay for a better EJB spec. no ?
Actually, this has happened before… log4j more or less became Java 1.4 Logging API. I would expect something similar to happen with EJB3. The persistence mechanism will be “Hibernate-like”, but not necessarily Hibernate itself.
That said, who cares? Just as people are choosing Hibernate over EJB entity beans, people can continue to use it. May the best API win.
(As an aside here, Groovy is going through the JCP in order to formally standardize the language… but just going through the JCP does not give Groovy any kind of special status with Sun. At least, that’s what folks were saying when the Groovy JSR started up. EJB3, on the other hand, is a Sun-driven spec.)
I think there is a huge hole in the whole app-server Java world. Fact is that PHP, although far from perfect or nice even, has a huge number of advantages that the Java community seems to be completely overlooking.
Fact is EJB is too complex, EJBQL is too stiff and incapable. I have written extensively in Java believe you me, but php is way way quicker to develop in, and that’s with only a couple months of php experience.
Many Java people think php is just like jsp – aaaaaa! wrong! It’s way more than that.
Comments are closed.