Why I hate Spring

When I started my career I really fell in love with Spring. I went long on it. I threw it into all of my projects. I even managed to chuck a bunch of Spring Integration in there for good measure. I was like an XML king.  I was building was a custom RPC layer based over JMS, protobufs and Kaazing to be used across our department and further around the bank. “It’s so configurable” I would say. “It’s just a few XML files, it’s really flexible” I would say. I was pretty pleased with myself.

The thing is, there were some people around me that tended to disagree. They were having issues getting this wired together how they wanted, they didn’t know which spring XML files they needed where. There were issues with spring versions and getting the right versions together (I’d also gone long on modularisation; there was about 5 or 6 different modules at different version numbers with no obvious way, other than an email from me, to know which to use). I didn’t notice these smells; I just thought it must need more documentation or that the people using it were being stupid. This is a pattern that repeats itself too; for one of the most disliked and difficult to use frameworks internally currently cries for help are often met with “It’s one file and some parameters, it’s not that hard” whilst everyone else wastes days trying to get the magic combinations of files and parameters to make something happen.

I’m still in the same organisation, and in my new role I’m a consumer of my old framework. This dogfooding has now led me to hate 2009/10 era Sam for several reasons, but mostly for spring. Spring is evil on a good day, but when it’s included as part of a consumable library or API it becomes next level, like a love child of Hitler and the devil. Don’t let Spring leak out of your APIs.

There are a number of reasons why Spring sucks which I felt the need to document, as nothing’s showing up on google as a concise argument against it.

  • Configuration in XML : I’d like to think that as a profession we’d moved beyond XML. It’s incredibly verbose but that’s just a minor starting gripe. Much more importantly, I don’t want to program in XML. The wiring of all of your classes together is a hugely important part of your application. You’re a java developer, not an XML developer. One of the beauties of java as a language is compile time safety. In my springless applications I can hit compile and have a 100% certainty everything’s built, plugged in and ready to work. In applications I work on with Spring, you hit run, wait for 30-60 seconds whilst it initialises beans, before falling over. In the modern world we live in this is insane, particularly when you multiply that up over a number of integration tests where you need to spin the container up and down.   There’s also a special place against the wall for the “It means I can change my implementation without recompiling!”.  No one does this.  Ever.
  • Magic : At this point the usual come back is “you can do it all via annotations now! No more xml!”.   Whilst not programming in XML is swell and all, annotations are still magic.  Until you run your app you’ve no idea if it’s wired up correctly.  Even then you don’t know it’s wired up correctly, only that it’s wired up.  I don’t like magic.
  • Importing other Spring files : This is currently the item that causes me the most rage.  I’ve discovered there’s a tendency to break Spring files down into smaller spring files, and then scatter them across modules.  I’ve just spent 2 weeks of crawling through jars trying to find the right combination/order/version of spring files to make something actually run.  Spring files in jars is a bad, bad idea.  Terrible.  Every time you spread dependent spring files across jars a child dies.
  • Complexity : When interviewing candidates the most common answer to “any pitfalls to Spring?” is that it has a steep learning curve. Whether or not that’s true is another discussion for another day, but I wanted to highlight the fact that Spring is now so complex that it has it’s own framework, Spring Boot. A framework for a framework. We are in Framework Inception, a film about Leonardo Di Caprio trying to find his long lost java code by going deeper and deeper through layers of XML and annotations before eventually giving up on life.

The thing is, I’m sure it’s possible in theory to use Spring well in an application.  I’ve just yet to see it happen, and this is the problem.  And for me all of the “benefits” it offers are perfectly possible without it.  When asking about Spring as a part of our interviewing process and the standard answer is “it means you have clean code, separation of concerns, and it’s really good for testing”.  All things I’m huge fans of (in particular the testing part) but the simple fact is these are not outcomes of using Spring, but outcomes of programming well.  Perhaps Spring is a good crutch for new developers to use to be introduced to the ideas of dependency injection and mocking and testing, but the simple fact is they’re orthogonal.  If you TDD your code you’ll find no getters and setters, only constructor injection which you can mock for tests, and then when you’re putting your application together, just use the often forgotten about construct, the “new” keyword.  We often build a class called “ApplicationContext” which is in control of wiring everything together.  It’s clean, everything’s testable, I have compile time safety and my tests run darn quickly.



  • peterdrinnan

    Now that we have HTML5 and MVC front-end frameworks such as Knockout, AngularJS, Ember, etc, these is little need to rely on server-side frameworks for the generation of rendered content. Ajax is a great way to improve performance, but there is no longer a need to send html content over the network again and again. All we really need from the server is data handling. The amount of processing and bandwidth wasted with server-side MVC frameworks can really add up to serious $$$s on cloud hosting services.

    I used to rely heavily on MVC server-side frameworks, but now they seem largely redundant. Just give me a good API server framework.

    • PD

      There are still issues:
      All JS based frameworks suffer from maintainbility beyond a certain lines of code. we as developers forget that a good product will have a long time on maintaineance mode.
      I agree with you that what the front-end frameworks led us to that we don’t need MVC but MV* models going forward. I think Spring is a great choice to provide that API server framework. There are still transaction, caching, security, distributed framework if needed, persistence etc… that a server-side framework has to manage and provide.

    • Paul Rivers

      I just find most of these arguments to be smoke and mirrors.

      You have to render the content either way, moving it to the client just shuffles it around.

      I’m not at all convinced that sending it as json rather than html is significantly smaller, and whether it is or isn’t doesn’t really matter as rendering it takes a miniscule amount of server time compared to db access, and just a couple pics or 1 video make bandwidth html takes up insignificant in comparison.

      One thing you can rely on is that the multiple server requests and client rendering mean slower website response times from the users perspective. And client side rendering is more difficult to debug and harder to get error messages from.

      Moving html to the client side seems largely redundant to me, just a different way with more hassle to do the same thing.

  • avantgarde1310

    Thank you. I really needed these comments about Spring. I thought I was the only one crazy here.

  • Thomas Heß

    I just googled for “i hate spring framework” and came up with this post. I actually share pretty much the same history. I started my career with Spring and it was like the standard to use in real world. Several years later I was in a different project that did not use Spring but was using Apache Felix as a container. There I noticed how awesome code can be, if you don’t have to wrap your head around dynamic injections and optional dependencies in Spring.

    Actually I think that Spring has grown to such a ridiculous level, that it has basically wrapped any standard API of Java with a Spring replica that shares the same complexity as the original API just to be as flexible. So overall using Spring just adds more complexity and Jars to your application.


  • PD

    Does your ApplicationContext manages scope, when and how many dependent objects to create? Provides AOP? JPA, transactions, cacheability?

    • jastc

      This is one of the problems with Spring, it is a kitchen sink framework. Often, there are better frameworks for a particular behavior. However, because developers are already using Spring for DI, they use Spring for everything and many of those implementations are clunky and/or complex. Once example is the template pattern that is used everywhere. It forces a tight, compile-time, coupling on Spring while also still having the XML configuration on top of that.

      • c_world_poster

        Which is funny because, just like people said about Hibernate, they said it doesn’t do enough. Now, it is too much. The good thing is that you can ignore what you want and use what you want.

  • Nuñito de la Calzada

    couldn’t agree more, spring sucks

  • Maxi Wu

    OMG, I thought I was stupid that I put together some perfectly compile java code and that application server won’t event show me some html. I then realize that because there is something wrong with one of the configuration inside some xml inside some module that is not correct. I like that idea of spring, but those xml wiring is just making me crazy.

  • Alexander Scott Johnson

    It’s only magic when it actually works. The rest of the time it’s a 92 call stack-trace to a null pointer exception in some obscure library that was inadvertently loaded as a transitive dependency of some stupid conflicting thing injected by some bean configured by some idiot who left the company 2 years before you joined that was never removed because the complexity frightened everyone that looked at it and nobody left has any idea how it ever worked in the first place.

    • Jiří Kačírek


    • golfman484

      OMG – that is the funniest yet most accurate summary of my 12 month long experience with Spring that I have ever read :)

      Oh and when you do finally get the magic to work – your app takes 2 minutes to start up…

      • Thomas

        Takes ten minutes in the company I work in on modern i7 machines. Just to compile, then another couple minutes to start the web server.

        For every bloody java code change!

        • golfman484

          I’m hearing you bro!

          Up until working on this current Spring (crippled) app I was used to Tomcat apps that start up in sub 20 seconds, not minutes.

          Oh and the latest Spring craze that really messes with any logically thinking developer – Spring Boot – embedding the Tomcat container INSIDE your app. Ok, so let’s put the container INSIDE the app instead of the app inside the container like you normally do with “app” containers. Really???

          So the Java world has been using app containers for nearly 2 decades (Java servlet containers – tomcat, WebSphere etc.,) and now whole world is catching on and moving towards containers for non Java apps also by way of Docker containers… so then someone at Spring has a brain fart and says “Whoah, hang on, let’s turn it all inside out and embed the container (in this case Tomcat or Jetty) inside the app!

          And like lemmings over the edge of the cliff a high percentage of the Spring faithful think that is a wonderful idea!

          Priceless! You couldn’t write this stuff 😉

  • sam sneed

    I wanted to put some high praise in for the ActiveWeb framework. Its concise, well thought out, and minimal. Spring is just the opposite, its massive, configuration heavy, and the main thing is, when things go wrong, I like exceptions my brain can understand and find the problem. Once you walk the autowire dependency injection and god knows what else frameworks, most of the time you will just be looking down 400 exceptions to get to a system level null pointer that means nothing.

  • AsqUsTeam

    As a 30-year developer who just recently started to learn Spring, I have started to wonder: if Spring is the answer, what in the name of God is the question?

    • New Java

      How to employ unskilled programmers. The less they have to know to write a few lines of code, the better the framework! :-)

    • Chris

      When I first encountered Spring many years ago I asked the team I was working with why they were using it. The only answer they could give was “to wire things together”. Well I can wire things together with Java can’t I, so really, what is the point? I have battled with devs for years over this. I have even re-written entire Spring configs in Java, just to prove that you can get exactly the same functionality, with less code that is type-checked, debuggable and readable – as Spring is not. How this framework managed to raise itself to the heights that it did, so that most devs preach its virtues and demand knowledge of it to gain employment is just beyond me. That a professional engineer can actually think that you can’t do dependency injection (a trivial, basic concept with a ridiculous name) without an equally ridiculous XML-based “framework” beggars belief.

      One day it will die and the world will be a better place.

      • http://xenoterracide.com/ Caleb Cushing

        Spring has this thing called JavaConfig now… welcome to Spring 3.1… (note Spring 5 will be out this year but that tells you how long JavaConfig has been around)

        • golfman484

          That just shifts the implementation of Spring ‘wiring/injecting’ config from XML to Java annotations – it’s still totally unnecessary to rely on Spring to do dependency provisioning unless you really enjoy the obfuscation, runtime inefficiency and slow app start up times.
          If anyone can’t work out how to provision (not inject!) dependencies (interface impls) in a flexible way at runtime via one or two lines of debuggable java code and a brain dead simple properties file but instead needs to put on their “Spring crutches” to do that then they must have been asleep in the Java 1.0.1 session.

  • Pingback: Your Programming Language Sucks - Vegibit()

  • Alex Worden

    Can’t agree with you more – and Spring Boot has made things 1000x worse. Designing a framework that auto-configures, makes guesses, and changes behavior just because certain things happen to be on the classpath is the new strongly opinionated philosophy. Unfortunately is a terrible opinion that lacks experience is building usable software. The folks at Pivotal are all drank the cool-aid and are charging Spring full-tilt in the wrong direction.

    • golfman484

      And to make the whole thing worse Spring Boot, by default, puts the app container inside the app – an inversion of the time proven concept of an app container!
      Spring Boot breaks essential concepts, which is bad enough but to make this ‘slight of hand’ possible they have had to introduce their own class loader and that’s like the point in the Alien movie when the alien in that person’s stomach rips open the skin and emerges… OMG – if your app uses another framework which has it’s own class loader which works perfectly fine when your app is deployed in an app container in the “normal” way you soon discover a new type of hell when you try to run your app in “upside down” Spring Boot world :) We ended up aborted jar generation in Spring Boot and reverted to normal .war deployment after days wasted trying to get it to work the “Spring” way. We immediately banned all future ports to Spring Boot for the remaining apps.

  • dadepo

    I share the thoughts here…but the question I ask is “what is the alternative”? Any thoughts?

  • Nicolas Frankel

    I’ll try to be very factual despite the article being a complete piece of crap:
    * Configuration is in XML? Sure, it started like that. Now you’ve got JavaConfig, where you write your configuration in XML. This way, the compiler can tell you if there are errors. By the way, even with XML, if you use a professional IDE, you could have spot errors during development.
    * Magic? Sure, self-annotated classes were a bad solution to XML. See point above about JavaConfig. By the way, you should never autowire, but use explicit dependency injection. Too bad Spring offers both option, while CDI – the “standard”, only offers autowiring.
    * Importing other Spring files? Yes, modularity has a cost. But it also offers a whole load of advantages!
    * Complexity? Sure, any framework is complex. Java EE is complex. Hell, even the web is complex. Did I mention that HTTP is too complex for some people? That’s a very subjective argument I’m afraid.
    My conclusion is that you should really read more before writing, because that makes you look like someone who doesn’t know what he writes about… which is the case. On the positive side, that means you’ve much to learn! Just check the Spring documentation: for an Open-Source project, it’s very good (as much as JBoss).

    • lars

      Says article is a piece of crap, provides a list of counterpoints that proves absolutely nothing, ends of by getting personal and condescending. The most rude comment I have read all day.

      I for one agree completely with the author, and has long since moved from the magic configuration-hell that is Spring and EJB to more light-weight alternatives like Guice. I apologize for getting personal as well, but I can only hope you’re not in a position where you’re able to make any serious architectural decisions.

      • Nicolas Frankel

        My good man (if I’m being condescending, I should at least play the part),
        Either you didn’t read my points, or they are too complex it seems :-) Now for the meat: I’ve given counter arguments that are factual and easily checkable, something the initial issues don’t do.

        I’ve no issue not to use Spring and use Guice, CDI or do-it-yourself Dependency Injection. But at least whatever conclusion you achieve should be done because you know mostly know why you take this decision. This article does a disservice to the Java community at large because it contains just counter-truths and plain lies.

        (I’m doing some Android on the same and Spring is not the best choice here. I’m using Dagger 2 – which is heavily similar to Guice)

    • samberic

      Hi Nicolas,
      First, let’s stick to talking tech without cursing and making it personal. I love a good tech debate and I’m happy to have my mind changed. Strong opinions, weakly held.

      The post was written early 2014, which will have been just after Spring 4 came out. So sure, I don’t know about JavaConfig and I’m pleased if Spring has moved away from XML/annotation hell. But the point is still moot; there are tons of ongoing and legacy projects using Spring 2 and 3 that simply won’t move off them maybe ever. If you work in a world where everything’s moved up then great, but I get the impression from the sheer number of people who agree with this post that theres a lot of XML config still kicking around.

      “Sure, any framework is complex”. Surely that should be a smell for any developer? This is why in the framework vs library debate I sit very firmly on the library side. Absolutely fine if you like frameworks, but I favour simplicity in my codebase.

      • https://www.about.me/snicoll Stéphane Nicoll

        So your point is that Spring sucks because some of those who are using it haven’t upgraded their stack? Wow.

        I also think that the “hate” part was probably unnecessary. At the end of the day, the only thing that matters is what you’re ready to integrate in your application and be responsible about it. Being on the “library” side as you said sounds perfectly fine. Heck, having an opinion and being responsible about it is fine. But “hating” the other side is not IMO.

        Maybe you should “hate” your co-workers or those who are still using Spring 1.2 or something?

        • samberic

          Nope, was more saying that the point heat keeps getting brought up of “Springs better now!” Is irrelevant because there’s so much of the old world around. When I wrote this only the old world existed anyway.

          Agree that “hate” is a bit strong, but was more for a headline than anything. Although whenever I’m stuck in a spring hell i think hate is fair :).

          • https://www.about.me/snicoll Stéphane Nicoll

            > When I wrote this only the old world existed anyway.

            *Your* old world you mean? I think we can both agree that you haven’t seen all Spring-based projects on the planet, right? It is indeed “easy” (doable) to do things wrong (as with any stack I’d say). My own personal experience is that I’ve seen a lot of well designed projects using Spring (and some ugly too). At the end of the day, the team is responsible of the code and architecture they produce; blaming the tools/frameworks is really cheap but I guess you got that from my first answer.

          • samberic

            Sorry, old world I meant spring 3 vs 4. Either way, you’ve hit the nail on the head; any and all stacks (and libraries) can be used badly. With great power comes great responsibility. My point is, from what I’ve been exposed to, Spring has an incredibly high rate of people using it badly and resulting in projects that are difficult to run/use/modify etc.

            As I’ve said before, I’m really keen to see a Spring project done well. I am sure they exist; I still imagine I’ll find it too heavyweight, but that’s just an opinion and if it’s done well I’m sure I’d be fine with it. But all spring projects I’ve been exposed to have suffered from how Spring has been used.

          • OrbitManual

            I disagree. If a framework allows writing bad code then it is bad. I would not risk building a heavy application using Spring with X developers only to have a team of 10x developers to maintain it.

        • pclement

          Stéphane, Pivotal employees do have similar stance of other technologies and are vocal about it. See Josh Long’s twitter posts and conference talks. I’ve not seen you agitated then.

          • pclement

            I suppose I’d like to see Sam give ideas of what he’d like to see instead of us all being so defensive.

          • samberic

            More than happy to elaborate, if Pivotal would like to fly me to San Fran and/or give me a job I’m sure we could make something beautiful. Keep you enemies close and all that :).

      • Nicolas Frankel

        * So if to follow your reasoning, Java sucks because 1.1 had issues? And EJB because of v2.1?
        * About complexity, that’s quite easy. Is your point about framework vs library in general – then why target Spring? Or your application is so simple it doesn’t need any framework? Or your reinventing the wheel in each of your application? I mean, what stack are you using for web development? Java EE is quite “complex” whatever that means, and I’ve found Spring to ease my development every time. Sure, you’ve to read and know a lot: welcome to software development…

    • Dean Schulze

      Nicolas, what do you think about writing a new framework for the old framework: Spring Boot. Doesn’t that tell you something about the first 10 years of Spring?

      • Nicolas Frankel

        Spring Boot is an initiative to have a default configuration out-of-the-box, it’s not a framework (sigh…).
        I don’t know about your context, but a simple Java web project already takes ages to configure, not mentioning Spring/Spring Boot. You’ve to pick and choose your libraries, depending on your application server.
        For me, Spring dramatically improves Java EE application development bootstrap time. So does Spring Boot for Spring.

        • samberic

          “A simple Java Web Project already takes ages to configure”

          http://sparkjava.com/. One line of code, zero config and I’ve got a working web app.

          • Nicolas Frankel

            Zero config and zero portability. Again, I don’t know your context but my Ops would ask me how to configure that. Or your app doesn’t use a JNDI Data Source?

          • c_world_poster

            I think he didn’t mean “trivial”.

            FYI – or you can use Ratpack. And still use it with Spring 😉

            (although i did see a link on how to use Spring with Spark :) )

        • Dean Schulze

          “ages to configure” — The last one I did took minutes.

          As far as picking and choosing libraries, that is what Maven does for you.

          It sounds like you have no experience with the standards-based approach.

          • c_world_poster

            Maven does not. It can be done using Maven. And that is what Spring Boot provides, in part. What he is saying is that if you create a web app that does the typical thing – JPA, logging, web “framework”,- you will have to spend a little bit of time making sure all the different libs don’t conflict. Now, if you are using a JavaEE container and only use what it provides, then you probably don’t.

            FYI – even though i use Maven (well, Gradle but still) to get my client-side JavaScript libs (via webjars), i still have to spend time figuring out which versions work together. I wish someone would do a “AngularJS boot” with webjars.

          • Dean Schulze

            “Maven does not. It can be done using Maven.”

            Which is it? Please make up your mind.

            If you claim that Maven cannot do dependency management of java .jars please provide something to back up that claim. Maven manages transitive dependencies of Java .jars. I have not experienced it getting the dependencies wrong. If you have found an example the rest of the Java world would love to know about it.

            You do understand what transitive dependencies are, don’t you?

            Since when does Maven manage JavaScript dependencies? JavaScript isn’t even a real language IMHO. For better or worse we have to live with JS on the client side (we don’t have to ever use it on the server side, though), but JavaScript and its dependencies are a very different thing than Java and its dependencies.

            JavaScript is a house of pain. Don’t conflate Java and JS.

          • c_world_poster

            Read it again. Maven does not do it by itself – you have to do it USING Maven. And that is what Spring Boot does for me and many others (well, one of the things). One can build and test and maintain poms that ensure libs work together. Or they can just use Spring Boot.

            I am not saying Maven gets the wrong jars. I am saying if you get different libraries using Maven, you might (and highly likely will) get libraries that conflict with each other or libraries that they use. If you’ve never had this issue, count yourself lucky. Like i said, I can show you how it happened with JS libs in webjars. And those are worse because JS errors are usually horrid. But the same thing can happen with jars that only contain Java. I was only using that as an example and since I’ve been using Spring Boot , well i can’t think of a recent issue (although i am sure there was since I still need to use libs not managed by Boot).

            No need to be nasty. Or argumentative.

            http://www.webjars.org/ – “WebJars are client-side web libraries (e.g. jQuery & Bootstrap) packaged into JAR (Java Archive) files.” Sure, I can use bower, etc. but i already am using Gradle/Maven.

            FYI – I totally agree about JS. Argh!!!

        • Aluan Haddad

          I does not matter if it is a framework for a framework or an X for a Y, the fact is it is a “technology” that I have heard of, that has been marketed to me, that it is an initiative, and I work in C#/JavaScript and I’ve still heard of it.
          Spring Boot is a second order dependency marketed as a first order framework and that makes me immediately suspicious as to intent.

    • Dean Schulze

      Nicolas — Have you had a chance to reflect on how non-factual your criticism is, in spite of your claim to be factual? When you call the article “a complete piece of crap” in the first sentence you give the lie to your claim to be “factual”.

      By admitting that the XML and annotation configuration that Spring used for over 10 years were bad solutions you reinforce his criticism of Spring.

      Very little of what you write is “factual”. It’s mostly venom. The truth must hurt, and judging from the number of other comments here that agree it seems that Sam’s criticisms of Spring are valid.

    • OrbitManual

      You kind of support the article when you say “The correct way, you must use ‘this’.. too bad spring also allows that”. Well, why does it allow ‘that’? If ‘this’ was the correct way, why would spring give the wrong way? Would some new programmer have any clue what is wrong and right?

  • daniel

    disagree – not promoting spring or spring-boot here – but your points convey that you actually have no idea what your are talking about (your points just fail…)

    • RayAndyJenkins

      And “disagree” without further weight convey that you’re a moron.


      • strange_loop

        Saying “I hate Spring” without offering any alternatives is not much better either.

        • Dean Schulze

          What part of Spring do you need an alternative to?

          I’ve been a Java developer for over 15 years and the only times I’ve used Spring is when doing maintenance on legacy code. I’ve never used Spring on new projects because I just don’t need it, and I don’t know why anyone would introduce all of that unnecessary complexity into any project.

          • strange_loop

            I don’t know the sizes of the projects you have been working with so far but managing DI manually becomes a pain in the ass after a certain (not too high) complexity. Unit testing is very easy with Spring, let alone integration of modules in a microservices architecture. Try to set up a cloud-native multi-tenant 12-factor enterprise application with service registry, API gateways, centralized configuration management, circuit breaker, and all the bells and whistles, then do the same with Spring and compare the needed boiler-plate stuff and plumbing. The difference is striking.

            You have never used Spring on new projects, so there’s a chance you don’t even know if you need it. Spring does add complexity as you have to learn new concepts (constant learning is part of this profession anyway, or you remain mediocre at best), but in turn it handles all the plumbing and you only have to concentrate on the truly important parts.

          • Dean Schulze

            What is manual management of DI? DI is done by a container and typically all you need to do is include a manifest of injected components. Java EE containers do DI and I’ve not had a problem even with very large applications. And Many Java applications don’t need DI.

            I doubt any project “needs” Spring. Is there a good example of where Spring adds significant functionality or simplification that I could not get with a standards-based technology?

            For example JPA offers a lot that you can’t get with JDBC, but I haven’t seen where Spring offers any significant advantage over standards-based technologies. It always seems to come down to preference for the non-standard approach over the standard approach.

          • http://xenoterracide.com/ Caleb Cushing

            what container do you use? I found Wildfly to be the most painful thing in the world, and Glassfish doesn’t seem to get regular updates so it doesn’t seem to be a good thing to bet on security or stability wise.

          • golfman484

            Let’s step back from “dependency injection” for a moment and abstract it to a more generic concept of “dependency provisioning”.

            Quite obviously there are many, many solutions to the dependency provisioning problem that don’t require you to hard wire your app to instantiate a particular dependency.

            “Injection” is but one of these solutions but if you spoke to any Spring people it seems like it’s the only solution they have ever heard of or considered.

            They also assume that anyone not using Spring can’t possibly create an app that employs separation of concerns, layering and dependency provisioning.

            It’s awesomely enlightening to realize that the above assumption is complete BS and you can actually create a lightweight Java app and compile all aspects of your code and debug your code just like you could 15 years ago – amazing!

          • c_world_poster

            I’ve used Spring from the beginning. It allowed me to throw away a bunch of my own code. With Spring Boot, i was able to do it again. If one is only using the IoC/DI part of Spring, then, i guess, I can understand. But Spring is so much more than that. From my perspective Spring has allowed me to reduce complexity.

            The alternative is – if you don’t use a framework, you will be writing your own, in one form or another.


          • Dean Schulze

            I’ve never suggested that you don’t use a framework. My strong preference is to use standards-based frameworks over proprietary frameworks.

            Spring was a nightmare to configure for over 10 years. Maybe they’ve finally found sanity when it comes to configuration, but I see no reason to bypass standards for Spring or any other proprietary framework.

          • c_world_poster

            Agree. Use standards were you can. And where they work best. And where TCO does not exceed the value. I do things outside the Java EE box (i.e. .NET :( ) and the value the Spring community and products out weights using only standard-based frameworks – FOR ME. YMMV. We all have different needs. For some, Java EE will 100% work.

            As for Spring being a nightmare to configure for 10 years? No. It might be for you. It could be a pain sometimes. But i have done programming without it. Before and afterwards. That was/is a nightmare. Every time i have to do .NET i think … i wish Spring.NET and NHibernate were not dead/behind. And i so wish that there was a Spring Boot. Of course, it does not help that there is no Maven/Gradle for it. (no NuGet is NOT).

            About 10 years ago i was working with a guy who was the .NET architect and i was a contractor (funny enough I was doing Java, ASP, ASP.NET, VB.NET, C#, VB6, COBOL/IMS, and etc there :) ). He was trying to – effectively – create his own IoC/DI framework. I said just use Spring.NET. He kept trying to reinvent the wheel. Finally he got it and just used Spring.NET cause it had everything he was trying to build. Sadly there was another group building their own ORM (instead of NHibernate).

        • Philippe

          I am +15 experienced Java DEV with many excellent references in companies and 5 stars on telecommuting jobs.This to say people usually believe i know what i am doing.

          Its true that in my carrer i have seen many times Juniors enthusiatic with frameworks while senior like me can wire up a web application in no time with a few jars.

          When things gets complex , the framework fails to delive the promise.
          As an exemple , paginated DB queries with hibernate beyond simple beans queries abruptly becomes drastically more complex and inefficient than plain SQL ( the point was technical , i forgot it at the time i write the lines to be honnest. )

          Also in 100% of the place i have been working with , apps where largely overdesigned. with a nice javascript/gwt framework , possibly a persistence framework ( i would now rather use a java sql binding like jooq) you’ve done most of the apps.

          Most of the people use that . ok . Most of the people have have average skills , ( its the middle of the Gaussian ) and average tools , make average decisions.

          Maintainace wise i have seen many misuse of spring because manager believed using a technology would be cheaper than hiring good coders and let them choose what they want to.

          An example :
          Spring app written by coders where multiple serialization where use between client and server : url encoder , form encoded, Json.

          Spring also tends to swallow and hide libraries. Should i need an xml config
          ( well usually its 1 page of xml so i dont bother using a framework for that, there is ‘simple’ java xml library which does the job )

          Maybe its just that i did not work for ‘the big one’ but as i said , 90% of the projects are stupid LAMP applications.

          • c_world_poster

            I know. Lets dump all these high level languages too. They hide too much and have too many dependencies Back to Assembly. I think that is what you meant. I couldn’t tell.

  • http://g00glen00b.be g00glen00b

    – Configuration in XML: Well, you can configure your same XML context files now using Java config, providing you the compile time safety you always wanted
    – Magic: “Magic” is actually very common amongst frameworks, perhaps it’s even the sole purpose of frameworks. A framework is there to make things easier for you, so you don’t have to re-invent the wheel over and over again. However, that means that it does a lot of stuff for you, and yeah, that’s magic. If you don’t want magic, I don’t think you should use frameworks, at all.
    – Importing other Spring files: Ok, but that’s your issue of having a bad, over complex project structure, it’s not the fault of the framework. I’ve been using Spring for a few years now, and I don’t import files from everywhere, and if I do, I put all @Import annotations at one place, so that it s till is managable.
    – One of the main issues that non-Java developers say about Java is that it’s overly complex, so in order to counter that, you see various frameworks popping up that are automatically configured using their opinionated configuration. Frameworks like Spring boot and Dropwizard are perfect examples of it. It’s just the next evolution in the framework landscape.
    In a world of many startups and MVPs that have to be setup, opinionated frameworks are like a gift, they allow you to do the basic stuff in a minimal amount of time.

    • Dean Schulze

      “…opinionated frameworks are like a gift, they allow you to do the basic stuff in a minimal amount of time”

      The “basic stuff” is useless most of the time in the real world. I develop for real-world complexity, not the contrived things that Framework “Quick Start” docs show. It’s often a big step from “basic stuff” to real world complexity. Frameworks can introduce problems that can be hard to diagnose.

      • http://g00glen00b.be g00glen00b

        I don’t agree upon that. It’s quite often that you need to do the basic stuff, for example, how many REST services did you write so far? We write several REST API’s/year, and with Spring boot you can set them up in no time.

        True, there are cases that Spring boot won’t cover, but it has A. a way to configure them using YAML/properties and B. it is still Spring, so you can configure your beans the way you want.

        • Dean Schulze

          I’ve written a few dozen REST web services. REST is just the interface. The business logic is the challenging part.

          REST is a good example of Spring wrapping an interface with its own interfaces (or substituting its own annotations for the standard annotations). JAX-RS implementations make writing REST easy. Do you have any metrics showing that Spring offers any productivity improvements? What about maintenance. How long does it take to trace down a problem in Springs internals?

          A couple of weeks ago I saw a Spring Boot demo showing SOAP web services in Boot. The annotations were so similar to JAX-WS it was laughable.

          I call Spring the “me too” framework. JAX-WS has standard annotations that simplify creating SOAP web services. Spring has similar annotations: “Me too!”.

          If you or anyone has any real metrics showing that Spring offers productivity or quality improvements over the standard frameworks and libraries I would like to see them. Otherwise its just fanboy preference.

          • http://g00glen00b.be g00glen00b

            The business logic does not change, whether or not you’re using Spring. It’s still Java.

            Metrics are hard to provide, neither can you provide metrics that JAX-RS/JAX-WS are easy to set up, which usually depends on the vendor though (I’ve seen that CXF configuration is a bit more complex than for example RESTEasy or Jersey).

          • http://xenoterracide.com/ Caleb Cushing

            you realize that some of the “standard” annotations were essentially copied from Spring right? Spring was doing CDI long before CDI. I can’t really comment on JAX-WS specificially, haven’t used it.

          • Dean Schulze

            I credit Spring with successfully incubating some technologies that found their way into standards. But that doesn’t make Spring a good choice. It’s got too much junk in it.

          • http://xenoterracide.com/ Caleb Cushing

            personally I like that *junk* it’s usually easy to get Spring to do what I need it to do, and I don’t have to invent something to get it done.

      • http://xenoterracide.com/ Caleb Cushing

        also want to say I agree with the sentiment, but not with Spring. I’ve seen a lot of frameworks that optimize for how fast they can write “hello, world”, I don’t see that Spring Boot is trying to do that.

        Spring Boot does a good job of scaling up and out. I need to connect to a database? easy, just provide credentials, later if I want connection pooling I write the connector and spring will get out of my way. perhaps an even better example, I need json serialization, do I have to setup object mapper? no spring will do that, but if I need to hook in and customize it, that’s also easy.

  • Dean Schulze

    Thanks for this article. I don’t know why it took a year and a half for dzone to pick up on it.

    I’ve done maintenance on a few legacy Spring applications. (I would not use it on a new project.) The code has always been a mess. Spring seems to appeal to novice developers who like to let technology drive what solutions they offer to their end users.

    • New Java

      Correct. As you have probably picked up on the “architects” of today are people who pick up some framework and beat it around the company. Few if any could tell you the performance impacts, the development effort impacts, or anything else useful. Oh, but angularjs this and dagger that. Time wasters which solve zero technical problems but create numerous new and very troublesome technical problem.

  • Phillip Webb

    I wrote a blog called “How not to hate Spring in 2016″ with some best practices that will hopefully help with some of the issues raised in this article.


    • Itsik Saban

      Yes, but as AsqUsTeam said above: “if Spring is the answer, what in the name of God is the question?”, maybe I will learn how not to hate Spring in 2016, but why should I like Spring in 2016? Or in other words, what benefits do I get from it that I could not get with plain old java factories/constructors?

      • New Java

        Ever hear of AnglarJS? I haven’t looked at the latest but the first version was a mess. Talk about a way to build unmaintainable code. Like with Spring and many other frameworks, no technical problems are solved. Give me a library that does something useful and solves a technical problem, not one that tries to define an architecture and does it in a messy way.

        • Gilbert Nwaiwu

          I feel the same way. Angular 1 was a mess. Granted it made building SPA easier. Building an SPA with pure JS will take more time(especially for a junior developer). I disliked Angular because it reminded me of Java. I dislike Angular 2 because it still has a bunch of config and verbosity that gives absolutely no advantage compared to something like React.

          React is down to earth simple and makes my work so much easier. Even a new hire was able to learn and start contributing to a project within a week. That’s what I call productivity.

      • Thomson

        The question is: How do I stop spending 2/3 of my time as a developer setting up projects and writing boiler plate code.

        The problem is when you use Spring for anything else you will have a problem.

  • Tom Verelst

    I’ve had all those problems when I started, but Spring does not suck because people suck at correctly configuring their application or using the dependency injection system. Not every class some developer writes needs to be a Spring bean, which I see many often do (I used to do this too, I admit). People having problems tying up multiple Spring configurations need to learn to how to split them up correctly and set up bounded contexts like you try to do in your code.

    Spring is not only about dependency injection. The reason why I love Spring is that I can setup applications so quickly without having to spend a whole day configuring boring things like transaction management, servlet filters and JMS connection factories.

    Spring has come a long way since this blog post and has addressed some of the issues already. I’m sure Spring will continue to evolve fast and become even better than it already is.

    • golfman484

      I’m sure they’ll add a lot more code to it, make it a lot larger and manage convince more people like you that they can’t possibly live without it.

      If you can’t do anything that Spring offers (ahem obfuscates) without the ‘crutch’ of Spring in a couple of lines of simple, compilable, typesafe, debuggable Java code without the runtime time bombs of annotations then you’re really not trying.

      I’ve worked with a lot of Spring evangelists of the last 10 years and I must say they aren’t as zealot-y as they used to be.

      Java without Spring can be very lightweight and can easily compete with the onslaught of new lightweight stacks in new “flavour of the month” languages. I know, I’ve done it and continue to do it without Spring.

      Java with Spring refuses to be lightweight in any sense of the word and if you choose to use it you will have no chance of writing lightweight apps like those written with the new lightweight stacks that use other languages.

      • Thomson

        Of course I can do what Spring magically does. But in Spring I set up a git repository including a maven project with external data access (doesn’t matter if SQL, Mongo DB, Elastic Search whatever) in 10 minutes and get my Microservice/-application running in two to three hours (inclusively writing the Repositories/Daos from scratch). And switching from one technological representation of my data to an other one takes about five minutes (just change three lines in the config file). And setting up a deployment queue is also quite simple, since all Spring Boot projects work the same.

        When I do it by hand I am lucky if I am finished with setting up the project and figuring out which jars I need during that time.

        Spring is a nightmare for APIs or Monoliths. But if you just stick to its conventions and you get your stuff running in no time. You just don’t need to care about the boiler plate code anymore and just concentrate on your application logic.

  • http://xenoterracide.com/ Caleb Cushing

    As a former Perl developer that came to Java around 2 years ago, and tried Wildfly and Standard (EE) APIs first. Spring Platform (the BOM and Spring libraries) are awesome! do they have warts? sure but what doesn’t. I spent weeks trying to get simple things working in Wildfly, Much of the time in Spring they just work. Maybe there’s something better? but I haven’t found it yet.

  • jerome angibaud

    Spring-boot didn’t solve the XML/Script issue : even if you can do all spring configuration with Java and annotations, you still have to deal with XML or Groovy for the build part.
    Hope that this build tool that fix this more general issue will gain interest from the community.


  • Jasiu G

    I wonder what are the real benefits of using spring. When I compare it to using Node or Django/Rails I see no advantages.

    Performance ? Rails/Django servers are cheaper than Java servers, you can buy performance way cheaper simply by using more/better machines
    Testablility ? You are way more productive in Django/Rails – all the time you wasted searching through 400 line stack traces of Spring, you could have better spend on writing a badass tests-suite
    Ease of use ? When a HelloWorld app takes 60 seconds to spin up on a MacbookPro something went terribly wrong.

    Please provide me some examples why should I use Spring(I would like to, but I struggle so much). What kind of supercomplex enterprise problems do you find it good at ?

    • Zaier

      Why I do love Java Free OpenSource
      Great Community
      IDE best support
      N°1 Choice for entreprises Apps
      Integrity with many Java Libs/Framework
      The easy Java Language if u new to learn Java

  • John Hogan

    Well said Sam. The xml is optional, but everyone still does it. The magic is real and mysterious. Importing other spring files to pickup the wrappers they put on the wrapper classes with layers of interfaces thrown in for good measure. It’s amazing and look inside your war file to see the huge number of jar dependencies. I’ve recently seen a simple backoffice web app whos .war file is larger than a complete wildfly server install. The builds are slow, startup is slow looking for beans in all those jars … And finally, the complexity is mind boggling. Productivity suffers.

  • Little Santi

    I agree 100% with your article, Sam. Lack of *compile-time safety* is the main drawback of Spring as well as all of those configuration-strong-based frameworks that do-it-all in runtime.

    Moreover: Spring per se does not gurantee your code will be free of hard-coded module dependencies. Spring allows you to get rid of hard-coded dependencies, but won’t prevent you to [accidentally] introduce them in your code.

    See my blog about undesirable dependencies in Java: http://java-built-in-flaws.blogspot.com.es/

  • Brett Ryan

    I loved spring, I did everything I could to externalise my configuration. It’s not that bad if you use the beast right.

    But, then along came annotated configuration, which sounds great but you’re sticking your config inside the jars undoubtedly. So you do what you can to stop that by use of @Value annotations all over the place.

    I can live with that, but what I hate most of all now is boot. Boot just takes every tiny magic that spring does and turn every f’ing part of it on, all at once. I find if I have any configuration more than the sinple example I’m spending more time trying to figure out how (and what) to turn off.

    Just because I have h2 on my classpath doesn’t mean I want to start a database, or because I have DataSource bean mean I want a JdbcTemplate. My apps often have multiple data sources which when I configure them boot expects only on and starts spewing exceptions at me.

    When I walk into my house I don’t want every device turned on at once, I want to turn it on and know how to turn it on, boot is the opposite, but all the switches for turning things off are hidden.

    So you think “I’ll just read the docs/samples” which don’t bloody explain how things work, just tell you “just include this dependency and boom you’ve got feature X”.

    So you ask about it on their forums and you’re shot down for not accepting boot.

    • Phillip Webb

      If you want to use the embedded servlet container features of Spring Boot but you don’t like auto-configuration try excluding `spring-boot-autoconfigure.jar` from your dependencies (or not including it in the first place).

      The core features of Spring Boot are designed to work independently of auto-configuration, and you might find that more to your liking.

      • Brett Ryan

        Thanks Phillip, I’ll try that for my next project. I’ve not been motivated to use boot for the embedded container features but only because I have wished to adopt the direction that spring has moved, which is primarily boot focused; such as with the examples all being boot based now days. And when you ask for non-boot help you’re told “use boot”.

        IMHO a transient dependency should not do magic, and that’s exactly what `spring-boot-autoconfigure’ is. It’s evil black magic that should be an opt-in.

        If I were to do as you suggest, and still use my own container, what is it that I’m getting over vanilla spring? If it’s nothing, then why is ALL of the documentation (apart from the API and reference docs) boot focussed?

        • Phillip Webb

          There are a few additional features that you might want (such as relaxed binding), but to be honest it sounds like the project probably isn’t for you.

          > why is ALL of the documentation (apart from the API and reference docs) boot focussed

          Because we’re a small team working on open source and trying to balance the needs of a large community. Using Spring Boot for https://spring.io/guides has allowed us to create a fair amount of useful content in a concise way. Using manual configuration and multiple deployment options would make it harder for us to write so many guides and test them.

          I wish we had more time to spend on this, or had more community contributions that we could add to http://spring.io.

      • Brett Ryan

        To be fair on spring boot. I value it, and being a spring user for the past decade and a half being an early adopter of spring. Maybe that’s my downfall? I’ve been in the trenches for too long with the old school.

        I have, for every version of spring in action relearnt old things, I haven’t bought the 4th edition, maybe I should.

        I guess the real problem I face is that starting a spring-boot project is NOT the same as starting a spring project. Which IMHO starting a spring-mvc project isn’t that difficult, it’s easy to understand, theres’s no parent pom, it’s just a java-web project with a special servlet container, everything’s opt-in.

        But then I start a spring-boot-starter-web and am constantly baffled about what I’ve just done more than getting work done. I’m still a tiles user, I love tiles, I still do most things the “spring 3 way” but take advantage of spring 4 features.

        Maybe what we need is something to migrate us old dogs to boot. I could bet you that everyone that’s in my boat wants to know exactly what’s going on rather than putting in the least amount of effort to make something work.

  • New Java

    Interesting article. My conclusion is programmers who graduated in this century were not trained in computer science. Dagger, Spring, et al break the ability to design powerful class frameworks. Yes, I know, you can’t hire unskilled people when you have a complex class framework; so, there you have it: Spring. Working with a a pile of Dagger mess created by a vendor from Austin now. It is horrible how much code they copy-n-pasted. Well, they had to as that’s how Dagger wires mess up. The whole code base could have been done much better with 1/10th to 1/4th of the amount of code by someone who had a good OO class. Alas, doesn’t seem those folks exist any more. So we slog on with configuration and compile-time binding frameworks. what a waste of effort.

  • tonyc236

    Spring for newbies

    Newbie Spring Developer: Show me my Swallow

    Spring: I can’t find your Swallow.

    Newbie Spring Developer consults google and attempts to adjust the application configuration.

    Newbie Spring Developer: Show me my Swallow

    Spring: Is that an African or European Swallow?

    Newbie Spring Developer: How should I know? Arghhhhhh

    Newbie Spring Developer consults google and attempts to adjust the application configuration.

    Newbie Spring Developer: Show me my African Swallow

    Spring: You have only specified European Swallows

    Newbie Spring Developer: Arghhhhhh

    Newbie Spring Developer consults google and attempts to adjust the application configuration.

    Newbie Spring Developer: Show me my European Swallow then

    Spring: Our internal processes returned null but we’re not treating this as an error and as far as we’re concerned you got your European Swallow.

    Newbie Spring Developer: Arghhhhhh

    Newbie Spring Developer consults google and attempts to adjust the application configuration and on and on it goes…

    I see I’m not the only person who has developed a hatred of Spring. I work for an organisation that is gradually moving existing applications to Java and Spring is the framework of choice. I’m trying to learn to use Spring. Rather than just copying an example I thought I’d be clever and use the Spring Initializr to create a simple Spring Boot project and configure the resulting project to create a “hello world” application similar to the examples that can be found via google. Having spent 5 minutes coding a simple “hello world” exercise a la numerous examples found on the web I’ve now spent hours trying to work out what the problem is with the configuration that is causing a 100% failure rate when it comes to displaying said “hello world.” in a browser.

    Coming from an “if it won’t compile then there’s nothing to execute” background I find that I am now confronted with black box applications will almost certainly will compile but you won’t find out until runtime that there’s what should really be compile time problem masquerading as a runtime problem. It may come with a load of exceptions caused by an improperly configured “bean” or a runtime dependency that some say is needed and others say it isn’t. Who knows? When there are no stack traces you have to try to find the one message in the hundreds that are spewed out by the logger when the server starts that might give you a clue as to what the problem is. I have now abandoned the simple exercise I was trying to do and resorted to plagiarism.

    If I were evaluating spring for my own use it would have been rejected.

    BTW. I had a go at ActiveWeb (mentioned in some other posts) and after a couple of hours found I was able to change a sample CRUD app to actually do the update that wasn’t implemented in the sample.

    Rant over, donning my flame resistant jacket.

    • golfman484

      100% Amen brother – I feel your pain.

      Java was designed to be lightweight, debuggable, typesafe, fast, simple, portable. Add Spring and you’re only left with the last one.

  • http://gauravabbi.blogspot.in/ GAURAV ABBI

    I feel it unnecessarily adds complexity to a application (making my type safety weak, the compiler guarantees are no longer so useful). I have never been comfortable using spring, but unfortunately there is not even a single employer I have encountered so far who does not like Spring. It seems the top decision makers do not ally with the opinion that using Spring is bad. Hopefully at some point, world will change for better.

  • OrbitManual

    Should I take a job that requires Spring and get 50% pay hike or another that lets me choose what language/framework but only about 15% pay hike? I need to choose one of them. The Spring Job currently appears to be gateway to hell, based on my experiments with Spring (I never used it before, I don’t even know why they are hiring me as they know this).

  • Alex Torstling

    I wholeheartedly agree with you, but have a hard time finding any sympathy in my dev teams.

    I have good knowledge of Spring and usually help others finding obscure bugs due to misconfigurations and subtle finnicky things in this slow, bloated reflection-based framework from hell – “you need to make that method public for weaving to work, you used an annotation with the same name from another vendor there, you didn’t disable log-every-url-the-app-ever-has-seen there, you caused that bean have session scope there” and so forth…

    Even though people struggle IMMENSLY to get their sh*t working with Spring and would most likely be 10x more productive without it, they all seem to develop some sort of bond with it. Is has some sort of magic allure.

    After thinking about it quite a lot I think it offers an illusion of simplicity. Your code usually looks very clean with Spring, even though the actual functionality might be close to impossible to deduce and require very detailed knowledge of framework internals.

    A vanilla app with no frameworks and just libs would look more procedural. The framework makes most procedural parts implicit. That to me is actually a huge problem, since tracking down errors might require serious debugging skills with Spring, while it would only require stepping through the app if it was vanilla. But most people seem more impressed with the lack of code.

    Another factor I think has an effect is the illusion of control and stability. You regard the framework as solid ground in the marshlands of development. You get something that you can learn and teach to others. Some people seem to value that so much that they actually don’t care if it lowers their productivity.

    With all this said, I do think that Spring provides good quality libraries. But the framework part of it must burn.

  • Frits Jalvingh

    Thanks for this breath of fresh air. I am constantly amazed by the amount of work that this “simple” framework causes. No one understands how it works so they make the most horrible mistakes in applications. When something inevitably goes wrong and you start to debug the only thing you ever see is layer upon layer of smelly Spring proxy crud infecting your code – you spend 90% of the time inside Spring black magic instead of in your code. Important concepts, like for instance entity manager lifecycle and transaction management are extremely badly described (and badly done). Not to mention the fact that with layer upon layer of extra framework your application is as flexible as a lead door.

    Spring is only easier when you make trivial hello world copies. For anything complex Spring is a complete disaster.

  • 范国刚

    by the way, I think this blog is kind of “标题党”, which means purposely using eye-catching title.

  • Stefano Cazzola

    Can’t help but share a lot of what you wrote, and, although the post is very old, I want to add my two cents. I honestly don’t mind about writing XML, but I deeply hate the automagical approach Spring has adopted over the last releases. As a side effect, I noticed that along with this automagical thing, also the documentation (which used to be very precise and detailed) has become a mere “do this, do that” without explaining the details of what’s going on under the wood, and mostly based on tuttorial projects, which are quite useless when you have to understand how to implement your own complex scenario.