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?
November 22nd, 2006 at 5:13 pm
I agree with many of your thoughts on framework adoption and the fact that too many teams spend an inordinate amount of time assessing Java frameworks. In my opinion, this is because most enterprise developers don’t feel comfortable with the current tooling/framework landscape. I speak to development teams on a daily basis, and I believe we have two distinct types of groups.
The first group is comfortable bringing in frameworks with little or no tooling/support. These shops have been long time JBoss champions on the server side, but they will often use Spring instead of EJB 2.x as an integration framework. Struts is also heavily used, despite the fact that Spring MVC is cleaner and a better choice for most groups. Of course, Hibernate is the 400 pound Gorilla in the O/R Mapping space. I believe this group represents less than a third of the Java development community.
The second group is not comfortable with Ant and the raw frameworks, and that’s the group that seam-gen addresses. Even great documentation isn’t enough for this group. I wrote the original seam-gen command line interface to directly address the majority of developers, but it’s not meant to be exclusive to this group. The beauty of seam-gen is the value and power it provides to shops that don’t just use eclipse and groups that are comfortable with ant scripts. Over time, I believe this approach to framework tooling will become pervasive. The fact that Seam is moving away from an EJB3 only framework to a POJO friendly framework represents another significant step in the right direction because many shops aren’t ready for EJB3.
With any luck, we won’t have to waste time convincing development teams on “our” set of frameworks. I’d like to see seam-gen style tooling for all major frameworks. That way, every Java shop won’t have to switch to Rails or switch Java frameworks every year. Rails and Grails have paved the way, and it’s time for other frameworks to catch up and leap-frog.
November 22nd, 2006 at 5:20 pm
BTW - I’m a Redhat/JBoss employee and a bonafied Seam proponent/contributor. My initial reply did not clearly state that.
James Williams
Solutions Architect
Red Hat
November 23rd, 2006 at 3:30 pm
James, That’s a very interesting conclusion: When most developers are not happy with current tooling/frameworks, what have we done the last five years? How could it be we have been idle all the time and need an eye-opener like Rails or Grails to get convinced that we’re not happy with our way of developing? When it’s really true, we all need a shrink, right now
It seems the first group you mention has been dominating professional application development in Java-land.
I agree with your observation the way software developer teams treat technical design will change using a seam-gen/rails/grails alike approach. And it is even something I encourage. At the shop I’m working I’m promoting the �one technical skeleton fits most’ approach heavily. Productivity will raise incredible when teams are using the same set of tools over and over again. And I also believe software development is not an issue about plumbing the invincible, that’s the area of code generation, automated setups, standard installs etcetera (yep, exactly the area where command line tools like seam-gen come in). Instead, software development is all about carefully placing furniture in an empty house.
Finally I would like to make one sidestep on your comment about EJB3 vs. POJO style. I do not think it is an argument to say some shops are not ready yet. Not ready implies eventually future will lead those shops into the arms of EJB3 (and so possibly in the arms of seam). Isn’t it a question of �not willing’. Somehow the need to adopt EJB3 is very low. And when that is the argument, a move towards alternative technology is reasonable. Very (and too) negatively spoken, the fact a framework like Seam is opening up for non-EJB3 approaches proves the failure of EE5’s( business) component approach. Or is Seam too impatience to wait until everyone is doing EJB3?