Howardism Musings from my Awakening Dementia
My collected thoughts flamed by hubris
Home PageSend Comment

Whence Spring?

I believe I first started using the Spring Framework in early 2005, and thought it was a wonderful idea and a well-done implementation. The 90K core was always a big selling point. I then proceeded to engineer all of my new applications with it, and most are still running years later.

However, I'm not sure I'll be using Spring again.

  1. Size Matters. The 3.2.2 release of Spring contains 26M of Jars. Even the core jar is no longer 90K, but now about a meg in size. However, the actual size isn't as much of a concern as the complexity added over the years. Spring is now a huge beast that does much more than just dependency injection, and it is harder to use just the core without the entire eco-system. Note: I do like many of Spring's component libraries, like RestTemplate† Did you hear the kids over at Apache replaced the old, stand-by, HTTPClient, with the new HTTP Components? .

  2. Complex MVC. After using convention over configuration frameworks like Grails, using Spring's web application framework brings back nightmares of typing all day and night just to get a hello world application running. I have found large applications written in it difficult to maintain.

  3. Difficult to Test or Difficult to Follow. The Spring liberation was with its dependency injection as an alternative to the J2EE bean wiring system, which made it possible to test everything. Seemed like a great idea until your XML configuration file grew to a megabyte in size and contained huge amounts of untestable business logic. The answer from the Guice Community and eventually Spring 3 was to use annotations. Improvement? Eh. Let me explain my lack-luster feeling:

Originally, Class A that needed to call code in Class B would call it directly with a method call. With DI, you create an interface that A now depends on, and you can now give A a reference to an instance of B in two ways:

  • Autowired. Looks for matching interfaces, and if it only finds a single option, it automatically connects them. This is generally discouraged (even those both sides have advocates).

  • Explicite. An annotation to A can specify what Class B reference it should get. At the Java level, there is no dependency between the classes, and during a unit test, a mock can easily be passed. This is good, but IDEs are now useless for following the chain of code without actually starting up a debugging session.

A better idea that seems to be catching fire is to wire up the dependencies with some glue code that can be tested for its interaction. Essentially this takes the concepts in Spring's original XML file, but uses either Java code or some JVM scripting language like Groovy or Clojure to stitch the beans together.

One thing that seems important to me is code organization. Frameworks that support convention over configuration and build tools like Maven encourage a standard placement of code that is obvious to maintainers arriving late to the party. Sure, it isn't a panacea (especially when designing REST applications), Spring MVCs approach to code location and structure is plain awful.

Better option? Perhaps using the code structure given by using the Dropwizard project with the lighter-weight Guice DI (see this project for how these two can be combined keeping in mind that we can combine Dropwizard and Spring as well).

Tell others about this article:
Click here to submit this page to Stumble It