Never thought I would ever quote Denis Leary in a J2EE context but I’m dying for coffee-flavoured-coffee right now. Just one (damn strong) taste of coffee which strikes the tongue and keep you awake. I’ll try to explain

The immediate cause: InfoQ’s has published an interview with Gaving King about the evolution of Seam, Gavin’s version of a framework telling you how to build (web) applications. I’ve written about Seam before and at that time in my opinion the framework was based on some interesting ideas and principles but lacked simplicity mainly caused by hard to set-up working examples. Never looked at it again (although the intentions were there ….) and I’ll point out immediately I’ll probably won’t look at it right now. So what’s so interesting about the interview? Besides some nice food for thoughts about the implications of a fine grained AJAX approach on database load and some old insights about the effects of state management on clustered environments, not very much. Except for one small comment Gavin makes as a reply to someone commenting exactly what has hit me one year ago. Let me quote:

Comment: I haven’t gotten the time to try out the new Seam release but I hope that setting up a project has gotten easier.

Gavin King’s reply: seam-gen makes it *super* easy, at least for EJB3 on JBoss users. We will be working on expanding the functionality of seam-gen to support other usecases (JavaBeans+Hibernate, Tomcat, J2EE, etc).

And that answer shows exactly what is completely wrong with the so called enterprise edition of java: There is no simple straightforward one-way road for doing things! Choices, choices, choices and a lot more choices that make life easy to model but hard to implement. Isn’t the power of application frameworks that choices are made four you? I would expect a framework like Seam dictates me to take the EJB3 route and pave things in such a way I really start to like the usage of EJB’s. Gavin, seam-gen is okay the way it is, actually it is right what was missing in your initial try. Instead of focusing on other choices, focus on more/better/advanced code generation! Expand into real functionality and help developers by filling room instead of giving it. Another illustration from the exact same interview: the different JSF frameworks Gavin lists. They seem to talk with each other to guarantee smoothness. Gavin calls this maturity, I rather use the term abstemious. A small sidestep without going into a fully blown JSF discussion but isn’t it remarkable (that’s the right word for maturity!) within EE we need a standard (JSR 299) as a glue between two other standards (JSF and EJB) in order to deal with application components in a unified way.

Right now I see a lot of developers (technical designers, architects, name them) spending too much ineffective hours on the which framework to utilize and which standard to adopt question. (not even mention the effort that can be thrown away due to steep learning curves and unexpected showstoppers after the answer to this question once again has lead to unknown trails). One can argue technical design is all about decision making and deciding what to apply is part of it. But in my point of view, technical design is all about the decisions that need to be made in order to translate a business problem into a technical solution. It’s not about choosing frameworks for every layer we can think of. Why are we programming Java? Not because at the start of every project we reconsider it. Nope it’s because we know the language and we know the language is capable of building what is desired in a (cost) effective way. And maybe once in a while we enter some self reflective mode to find arguments that reach beyond the arguments needed to make choices in a project context. And once in a while we pick up innovations, jump on bandwagons and maybe leave the paths we’re walking. Simply because we (as in the average software developer) know that when we do this every day, we can not keep pace with those who don’t.

Why is it frameworks and standards are treat in a different manner? What makes the adoption of yet another framework or standard so tempting?  The steps of changing seem to be relatively small. Due to the it’s all Java isn’t it and hey we have a new project so what the hack we’re here to learn aren’t we mentality, risks are not identified clearly. And as a result, unified application development is a farce and for every different twist, more glue is needed. And as soon as the need for glue is identified by more than one developer, new frameworks and standards arise.

Note, this blog entry is not meant to bash Seam nor the interview. It is meant to address a fundamental problem that has been floating around for a while and has been addressed in the past but seems to be persisting enough to get repeated every now and then. And Seam just functioned as a trigger (this time). Everyone who like to use Seam, go ahead, fine with me. If you do not mind, I’ll focus (projectwise) on a Spring based application design until Rails has really swallowed the way I think . But if you use Seam, stay with it at least the coming years (and so, stay with EJB3 and push Gavin to put all his energy in this choice instead of serving all other ways to technically layout an application).

A final thought: Is it a coincident Joel on software has published an article about choices (=headaches) on the exact same date as the interview publication? It probably is. But what Joel describes (15 ways to shut down your laptop) is exactly how we (as in the java community) build applications. Nuff said. Where’s my coffee?