Martin Probst's weblog

Spring MVC / web framework. not so l33t

Thursday, December 20, 2007, 13:03 — 2 comments Edit

I’m currently digging into the Spring framework a bit and just finished walking through the step-by-step tutorial. It creates a simple application that displays a list of products, and then allows you to increase the price of all of them. The price increase is validated and persisted in an HSQL database.

Behold the line counts:

      23 ./.classpath
      23 ./.project
      33 ./bin/test-context.xml
      16 ./
     308 ./build.xml
       5 ./db/create_products.sql
       2 ./db/load_data.sql
       1 ./db/
       0 ./db/test.lck
     151 ./db/test.log
      17 ./db/
      10 ./db/test.script
      39 ./src/springapp/domain/
      23 ./src/springapp/repository/
      48 ./src/springapp/repository/
      11 ./src/springapp/repository/
      20 ./src/springapp/service/
      53 ./src/springapp/service/
      11 ./src/springapp/service/
      29 ./src/springapp/service/
      36 ./src/springapp/web/
      46 ./src/springapp/web/
      37 ./test/springapp/domain/
      45 ./test/springapp/repository/
     100 ./test/springapp/service/
      26 ./test/springapp/web/
      33 ./test/test-context.xml
       2 ./war/index.jsp
      54 ./war/WEB-INF/applicationContext.xml
       3 ./war/WEB-INF/classes/
      12 ./war/WEB-INF/classes/
      18 ./war/WEB-INF/jsp/hello.jsp
       5 ./war/WEB-INF/jsp/include.jsp
      30 ./war/WEB-INF/jsp/priceincrease.jsp
      34 ./war/WEB-INF/springapp-servlet.xml
      33 ./war/WEB-INF/web.xml
    1337 total

So apart from telling me that either I or Spring are indeed totally 1337, how on earth do they justify this? To be fair, it’s about 200 lines less if you don’t calculate the DB log and the Eclipse specific files, but still, well over 1000 LOC for that?

What’s even worse is the number of concepts you have to understand. Apart from the probably ok Java and SQL stuff - why do we need a build file that says essentially “do as usual”, but on >300 lines? And in the particular funny ant style - lots of <property name=“src.dir” value=“src”/>. When did this change the last time? Why do we need a JSP taglib for even the most basic stuff? Separate setup for the application server for each tiny project? Three separate properties files? Lots of copying jars around?

And then all the XML configuration. >150 LOC not counting the build file. With gems like this:

      <property name=“driverClassName” value=“${jdbc.driverClassName}”/>
      <property name=“url” value=“${jdbc.url}”/>
      <property name=“username”  value=“${jdbc.username}”/>
      <property name=“password” value=“${jdbc.password}”/>
Isn’t that the kind of stupid, repetitive task we created computers for?

Repeated bloat

And it’s not just the one-time setup. Creating the form to increase prices with, i.e. a simple form to enter exactly one integer requires these five(!) components. The PriceIncreaseFormController (50 LOC), the PriceIncrease class to hold the integer(!) (20 LOC), the PriceIncreaseValidator (50 LOC), the priceincrease.jsp (30 LOC), and the XML configuration to glue it all together with 10 lines. That’s 160 lines of code for one simple form, without the code that actually performs the operation or any tests.

Loosely coupled XML

Something else that bugs me is the looseness of this thing. Not as in loose coupling, but as in “loose and falls apart”. Spring uses Java, a static, compiled, type checked language. This static-ness results in less expression, but usually better performance and earlier-caught errors. So far so good. But then we outsource half of our application logic into XML configuration files, with no checks at all. With an abundance of unchecked references to Java classes, field names, hard coded and duplicated URLs and so forth.

The benefits of a compiled language like Java are effectively eliminated by this. Typos in XML files will create NullPointerExceptions at runtime, refactoring doesn’t work anymore and the code cannot be understood as is anymore, but only through reading several XML files. This dispersion of single concerns into lots of files really scares me.

A better framework?

I wonder if this mess is simply due to Java or if there is a better way of doing this. I have seen references to Spring’s annotation based configuration, maybe that helps a bit. Even in static Java it should be possible to do better, with some reflection and by-convention magic.

You are absolutely right here. That loosely coupling and XML configuration in Spring is not good - although I basically like many of Spring’s other features.

But I actually see a positive future for Java in the webapplication space with OSGi and Sling:

OSGI gives you bundles (simple annotated jar files) that can be installed and updated on a running JVM - think of it as a very good plugin system (it actually works ;-). For inter-bundle communication you can provide services which makes the promise of component programming really come true while having a fully versionized software lifecycle management. The popular implementation in Eclipse is not making fully use of the OSGi features at the moment.

Sling on the other hand is a very cool webapplication framework that is still getting better. You can choose if you want to write your code in scripts (Javascript, Ruby, etc, anything available for the Java Scripting API) or with all the static-compiled Java features via OSGi bundles. Watch out for the upcoming releases of Spring.

Disclaimer: I am working at the company that started the Sling project ;-)

I fully agree with the issues you mention of using XML configuration in Spring. There are alternatives, one of which called JavaConfig which allows you to write the configuration in Java, with all the advantages that comes with it. Check out javaconfig here:

And here’s an interesting video presentation on “Ways to configure the Spring container”

Cheers, V.