About Johannes Brodwall

Johannes is the chief scientist of the software offshore company Exilesoft. He's got close to 15 years programming Java, C# and a long time ago other languages as well. He believes that programming is about more than just writing the code, but that too many people lose touch with the coding as well. He has been organizing software development activities in Oslo for many years. In addition, he often speaks at conferences all over Europe.

Why I stopped using Spring

My post on DZone about Humble Architects sparked somewhat of a controversy, especially around my disparaing comments regarding Spring and Dependency Injection Frameworks. In this post, I expand on my I stopped using Spring.

I was one of the earliest adopter of Spring in Norway. We developed a large system where we eventually had to start thinking about things like different mechanisms for reuse of XML configuration. Eventually, this evolved into the @Autowire and component-scan which took away the problem with huge configuration files, but in return reduced the ability to reason about the whole source code – instead isolating developers in a very small island in the application.

The applications tended to blossom in complexity as either the culture, the tool, the documentation or something else made developers build unnecessary layer upon unnecessary layer.

Later, I tried to build applications without a Dependency Injection framework, but taking with me the lessons about when to use “new”, when to have a setter or a constructor argument and which types were good to use as dependencies and which created coupling to infrastructure.

So I found that some of the instincts that the DI container had given me made me improve the design, but at the same time, I found that when I removed the container, the solution became smaller (which is good!), easier to navigate and understand and easier to test.

This leaves me with a dilemma. I found that the cost of using the container is very high – it creates a force towards increasing complexity and size and reduced coherence. But at the same time, it taught me some good design skills as well.

In the end, creating a coherent, small system is to me of much higher value than to create one that is decoupled just of the case of decoupling. Coherence and decoupling are opposing forces and I side with coherence.

At the same time, I found that the culture around dependency injection has a very strong preference for reuse. But reuse does introduce coupling. If module A reuses module B, module A and B are coupled. A change in B might affect A for better (a bug fix) or worse (an introduced bug). If the savings from the reuse are high, this is a trade-off worth making. If the savings are low – it is not.

So reuse and decoupling are opposing forces. I find myself siding with decoupling.

When there is a conflict, I value Coherence over decoupling and decoupling over reuse. The culture where Spring is in use seems to have opposite values.
 

Reference: Why I stopped using Spring from our JCG partner Johannes Brodwall at the Thinking Inside a Bigger Box blog.
Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

8 Responses to "Why I stopped using Spring"

  1. qnaguru says:

    Not just Spring, Hibernate is not necessarily good for most projects.
    I’m all for minimalism in design n code.

  2. JMS says:

    Completely agree. Spring framework is well intended, but all that configuration makes it more complicated than simply using a simpler and more mentally accessible framework. I dumped Spring MVC in favor of JSF2, which I like just fine. And yes JSF2 does indeed support IoC, which we only use to inject a few things into our 54-page JPA-Hibernate web application.

    • Whoa, JMS – I hope you don’t mind me saying so, but from Spring to JSF sounds like going from the frying pan into the fire. My personal bad experience is actually more with IoC containers a concept, rather than Spring’s specific implementation (although XML and component-scan are particularly evil).

      new is the new new

  3. leo says:

    Good and interesting article. Just for curiosity I would like todo know how you solve some common issues as transactionable methods, which I consider very important. In my opinion using Spring there is a cost we have to pay for automatize some common tasks. But always is necessary break the tend and think jeep in mind the specific domain. I celebrate your point of view.

    • Hi Leo

      With Java 7, transactions can be done like this:

      try ( Transaction tx = txManagemer.begin() ) {
      // Do something
      tx.complete();
      }

      These lines can of course be moved into Servlet.service in a super class if desired as well. But it’s literally only three lines of code. Hardly worth a whole framework.

      • leo says:

        well, that’s good…I’m needing a deep update about Java 7 & 8… I would like to run a webapp without Spring container to test the performance and other features… One point for Spring maybe is the rapid development, but as you said, some apps could require strictly performance optimization over development-time. Thanks for comment.

        • Rapid development with Spring is a lie.

          That is: Spring-MVC is a decent framework (as decent as you get anyway). But Spring as a container doesn’t help you go faster.

          Here is what I do:
          1. Add Jetty as a dependency to my project
          2. Create a main class that instantiates org.eclipse.jetty.server.Server and setContext to a new WebAppContext
          3. Run this main class in the debugger in Eclipse

          (Minor) changes in Java will be reflected automatically in the running code base. No such luck with Spring XML files

  4. leo says:

    Awesome! I want to try that!
    it’s absolutely true about the debuging time… thanks again for sharing your experiences.

Leave a Reply


seven + = 15



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books
Get tutored by the Geeks! JCG Academy is a fact... Join Now
Hello. Add your message here.