You Call That An Elephant?

The fundamental good in Elephant is two-fold: first, the message that EJB has gotten persistence wrong more often than not and that layering is always preferable to grand unified solutions.

The fundamental good in Elephant is two-fold: first, the message that EJB has gotten persistence wrong more often than not, and it looks to all the world like they are moving in that direction once again with EJB 3 in trying to hammer POJO persistence into the spec. And secondly, that layering is always preferable to grand unified solutions. Like Bruce indicates, along with others in the field such as Jeremy Boynes and Geir Magnusson ( and far more eloquently, to boot), the latest attempt to standardize EJB-based persistence along POJO lines has all the makings of an epic disaster. I have _always_ hated EJB entity beans, but EJB 3's POJOesque solution looks like it will be a real nightmare, particularly when you consider backwards compatible to "legacy" entity beans. I sincerely wish that the EJB EG reconsiders their ideas for EJB persistence, and go with a pluggable/layered approach instead of trying to re-write entity beans yet again (with the added bugaboo of trying to be backwards compatible with old entity beans as well). Do POJO persistence as a seperate and indepenent component service, and allow it to be used within an EJB world (or not, as your requirements dictate).

Unfortunately, the fundamental messages in Bruce's article are almost lost due to Hyde-esque rantings. Bruce makes the classic mistake of recognizing the failures of EJB entity beans, and then projecting entity beans failure on all the rest of J2EE. Bruce says:

So I ate entities, and gorged on both stateless and stateful session beans. I wrote my book and my courseware, and built best-practices white papers, and consulted. I ate it all. The thing was, I thought that after putting in all of that time, the elephant would sustain me for a while, that I'd be able to make EJB work. I expected to be able to camel those resources, and let the energy boost kick in as I needed it. And I'd occasionally have little victories, but big problems continued to plague me

In fact, the first half of the article is a whine-fest about how he was forced into EJB to put food on the table on his family, and all the woes it has visited upon him. His bullets reinforce this "I couldn't test the stuff", "I couldn't teach the stuff", "I couldn't escape". He goes on saying "And I stalked it for months, and like many customers, I never really completely brought it down, but I stunned it enough to start dining. And I ate: CMP, MDB, JNDI. And life was a little better, especially on the persistence front".

Like I said, I agree that entity beans basically suck. But I have the mental capability of carving entity beans out of the J2EE spec and finding alot of usefullness from the remaining spec. Bruce started out talking about persistence, but ultimately we find him trying to convince us that MDB's, and JNDI, and stateless session beans are horrors that have been unleashed upon us witless Java developers. Apparently, you can't test or teach a JNDI lookup, or coding a Message Driven Bean and the (horror of horrors!) onMessage() method - and neither can you escape them! Buwahahahahaha!

I don't know what the "right" persistence mechanism is. Maybe it is JDO, maybe it's something else. But it's sad and a little frustrating to see someone like Tate extrapolate the badness of entity beans out into the entire J2EE world. Perhaps I am some sort of super-genius, but I've never found JNDI or JMS or stateless session beans very difficult to understand or program to. Indeed, Bruce seems to be buying into the extreme "lightweight" camp to the point of implying that a onetime JNDI context setup somewhere and lookup code should be reserved for rocket scientists and 180+ IQ super brains, and that stateless session beans imply some boondoggle requiring several million dollars to develop and employ. Again, maye it's the super-genius in me but I recall developing a bunch of stateless session beans in about an hour. Hell, unlike Bruce I even managed to test them adequately.

I understand people's dislike, even resentment, towards entity beans. I can even see why a large number of people are drawn to the so-called "lightweight" solutions. But I think maybe people like Bruce are forgetting what software development was like prior to J2EE. I remember it - and shudder every single time I think of it. If Bruce considers J2EE "untestable" and "unteachable", he should try writing the applications he's developing today in C or C++.

I don't think J2EE is the be-all, end-all. Unlike some, I don't take the "elephant" whole - I recognize that J2EE consists mostly of pluggable components, and (gasp!) I can choose what components I want to use and what ones aren't suitable for me. I think where Bruce fundamentally errs is that he feels to need, and teach, and test _every_ technology that comes down the pike - an attitude I've never really understood. Where I come from, I don't pick a suite of technologies and then hunt for a problem that fits it. Rather, I study the problem space and come up with the solution that fits it.

About the author

Author:Mike Spille Blog: Mike Spille is an enterprise developer who has been living in the development world for a long time. He has written very interesting articles on topics such as distributed transactions.

Dig Deeper on JSRs and APIs



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.