I had a really eye-opening time taking part in a panel discussion at the end of the Javagruppen conference. Considering that in attendance were the guys who make Spring, a member of the Geronimo team, a member of the EJB 3.0 spec working group and several loud-mouthed interlopers (I consider myself firmly in that last camp), the panel discussion had a real potential to be a shouting match. Especially since there were some extremely declaratory statements made about the usefulness of EJB early in the weekend. It was a big pleasure, therefore, to see everyone really rise to the occasion and come to some agreement about the relative merits of the different approaches.

Most specifically, when one attendee brought up the question of simplicity vs. complexity, the discussion became really useful. It is just presupposed that lightweight containers are "simpler" and EJB is "more complex". But as Stuart pointed out to us all, sometimes it is pretty useful to be hit upfront with the complexity. EJB *is* more complex, but doesn't pretend otherwise. It can be useful to confront that complexity all at once if, in fact, you need all that complexity to achieve your end goal. If, however, your end goal can be achieved without it, then a lightweight container which doesn't pound you over the head with complexity up front can allow you to get your work done faster. If and when you need the complexity, you can lift the lid and look underneath.

The difference between the two approaches isn't so much the relative complexity, but the modularity and plugability of the different approaches. The lighter frameworks put a premium on being able to ignore features you don't need, and replace them if a better implementation comes along, while the "heavier" J2EE containers bake most of those choices into the framework and make you deal with the configuration complexity (at the very least) from the opening bell. But the truth is, sometimes that's just what you need.