Between skinny and bloated

Spring’s Rod Johnson writes today about the future he sees for Java Bloatware (his unkind term for Java EE middleware). Of course, as Mr. Spring, he is far from neutral. Of course he is focusing on a certain class of applications (web-centered, mostly greenfield, which is a huge – and sexy – segment, but not in any way the only kind of applications). Of course he underestimates how established technology that works remains used long after it may have ceased to be the optimal solution for new developments. But even taking all that into account, he makes some good points about the proliferation of rarely-used capabilities in Java EE and the associated cost. Most of those points are well understood and are driving the more modular approach taken by Java EE 6. As well as the adoption of OSGi (see here and here for BEA’s example). In addition, as Rod mentions, the JCP now has to share the playground with other framework standardization efforts like SCA.

The most interesting part of Rod’s post from my perspective, is this prediction:

“The market will need to address the gap between Tomcat and WebLogic/WebSphere. Currently an important part of the market is neglected. The majority of Java web applications are most at home on Tomcat. A minority actually want some of the more esoteric functionality of a full-blown application server, such as JCA, or specialized capabilities such as distributed transaction management. But a larger minority need some of the operational and management features of those products, but are not interested in the esoteric APIs and the bloat they bring along with them. As more and more end user companies look to phase out legacy application servers in favor of better suited technologies, there will inevitably be a response to market demand, with products that hit the sweet spot and bridge this gap.”

Right on. This is the second time in a week that we see an acknowledgment of the importance of application manageability coming from SpringSource. Whether this mid-point demand will be met from the top down by a more modular Java EE stack or from the bottom up by building on top of Tomcat (or some non-Java HTTP server) remains to be seen. The two aren’t exclusive either.

I expect that the hosted application frameworks like the recently announced Google App Engine will also aim at that “more than Tomcat, less than J2EE” sweetspot. But the cost/benefit formula of a more full-featured (or “bloated” if you prefer Rod’s terminology) environment might turn out to be different in a “hosted framework” situation.