Saturday October 16, 2004

The objections on principal may be technical

1. Intrusive inheritance hierarchy and mandatory interfaces, narrowing and recasting, gratuitous class proliferation and so forth (does the framework work for you or do you work for the framework?)
2. Container managed debugging nightmares

The philosophical objections are perhaps a general complaint about the Software Industrial Complex

1. J2EE is handed down from The Cathedral
2. JSR's and the JCP don't constitute inclusive openness, it's a "club" that you're either in or out of
3. Java is not open source

The practical problems of EJBs

1. Using the containers can be a morass of deployment descriptors and dependencies, slowing down project spikes
2. Component dependency on the container requires extra plumbing for testing, which also anti-agile. Specifically, if you want to use CruiseControl and Cactus together, get ready for a visit from an old friend named the OutOfMemory exception
.

While the practical problems of test-friendliness seem to be addressed by IoC, it sounds to me like some of the morass-of-deployment-descriptors problem are inescapable. Mapping services into POJOs declaratively (as Spring, Hibernate and Struts all require) isn't a walk in the park; until there's a linter and/or metadata/xdoclet support for easing how services can be mapped in given a specific runtime context, the pain of diddling XML config files and finding errors at runtime are going to be part of the landscape. Nonetheless, automated unit testing without cactus is a huge win in my book -- leaving CruiseControl to run unit tests and having Cactus runs reserved for manually-invoked integration tests sounds like the way to go.

I'll be steering clear of the traditional J2EE containers such as JBoss or Weblogic.