Spring - One Framework to Bind them All

A couple years ago, I was quite enthusiastic about the emergence of meta-frameworks in the Java landscape. Afterall, the land was littered with just too many frameworks. It had become increasingly difficult collect and select the best of breed frameworks to form a solution.

Back then there were several projects that aimed at providing a comprehensive solution. The most well known of them was Jaffa, Carbon and Keel. These frameworks cobbled together many of the existing frameworks to ease web development. That is they integrated security, database access, messaging, user interface, administration, cacheing, scheduling, reporting and more into a single cohesive framework. Unfortunately, despite their early successes, these meta-frameworks never really gained much traction.

There was indeed a real demand for these kinds of frameworks but for most it simply didn't pan out well. There was one framework however that did in fact gain real traction. That framework was originally hidden in the text of the book generically titled J2EE Design and Development. It was later rechristened as the Spring Framework.

There are many ways to cobble together frameworks, however where Spring succeeded is in the way it provided an elegant solution for doing just that. Not only did it address many of the pain points of J2EE development, it provided the solution in a platform agnostic manner. In other words, it didn't just provide a single prescription to the problem, rather it provided the prescription manual. To paraphrase "Give a developer a framework; you have fed him for today; Teach a developer to stitch together frameworks; and you have fed him for a lifetime".

The Spring Framework was primarily developed to support conventional web development. However in the past year, in a completely viral and decentralized fashion, new projects in other domains have emerged that are leveraging Spring's configuration model. Some notable examples are the ServiceMix JBI container, Acegi security framework, Confluence Plugins and the Compass search engine framework. It is one thing to see projects that enhance the existing tool set, however it's another thing to see projects taking the original concepts and applying it to an entirely different domain.

The Java landscape today has become directionless. There are just too many distractions like annotations, generics and EJB 3.0 that for all intents and purposes do little to improve the developers productivity. At the same time there is a "sea change" in software development that demands richer interactive applications and shorter development cycles. The steady decline of relevancy of the Java Community Process (JCP) has now become quite apparent. Although its comforting to know that innovation does in fact happen elsewhere. The one saving grace in all this is that we now have the "one framework to bind them all". Ironically that framework isn't even in the JCP.