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.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

10 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.

  5. Jama says:

    Spring gives you more cleaner and maintainable project in shorter period of time. Yes you are absolutely right when it comes to small/little projects :)

Leave a Reply


2 × nine =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
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.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close