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.

    • Robert Engels

      Check out the CUBA framework – you’ll never write client side JS again…

  • avantgarde1310

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

    • sarnobat

      Yep I too thought I was just being stubborn hating frameworks. But I feel like I’m at home on this page. After acquainting myself with a spring codebase the last few days I think there are some people who enjoy torturing me.

      What do spring and Jesus have in common? Their death will save us all.

  • 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 😉

          • kosgei

            I laughed too hard on this. Yes, the Spring boot thing is crazy, it is driven by the microservices craze. When technology starts to behave like fashion and starts to repeat itself in cycles, there’s a problem!

          • Anatoly

            People are crazy and lazy. Lazy to google/read docs/think just a little:) An example of a REST/webservice server/client on tomcat/jetty/netty/etc. is an absolutely straightforward class with just a few lines of code. All features/options of specific server is still here. Code is compact and clear. No unnecessary dependencies. No hardly manageable configurations. No useless and slow runtime magic

        • seahen

          Dagger would compile in less time than that, and not add any reflection or XML reads at runtime.

        • HaakonKL

          Have you heard of our lord and saviour JRebel? It really helps for a lot of projects.

    • http://kyleharrison.ca/ Kyle Harrison

      A few years back, I Inherited a mission critical set of Spring projects after the maintainer left. He assured me that “it’s easy, don’t worry” as he stepped out the door for the final time.

      I opened his documentation, and it basically said as such. No further instructions on anything.

      Thing was, we were php and python people. No one left on the team had ever deployed a custom Java app before, and we spent weeks of man hours learning Spring and fidgeting with and poking it just to get it to do SOMETHING

      At the end of the day, we found out the damn thing wasn’t really pumping out accurate data in the first place. So we just studied what the intent of what the code was doing, and ported it over to Python

      We cited the magic autowiring as a pretty big cause for confusion and waste of time figuring it all out. And it pretty much permanently painted Java in an evil light amongst our team and peers exposed to this guys codebase.

      In the past few weeks, I’ve been trying to sell my supervisor on the Spark Framework, but everyone in my team is super Leary about it because “it’s java” and we had an awful experience with it thanks in no small part to Spring.

      • mirak

        I think with Spark you can use Scala instead of straight Java.

        • http://kyleharrison.ca/ Kyle Harrison

          I’ve actually decided to put my money down on Kotlin in order to reprove the JVM usage to my team. Scala was a super close contender though

          • Paul Murphy

            Have you landed on a Web Framework for Kotlin? I’m super keen myself, but Kotlin + Spring seems to be gaining traction now, which is unfortunate.

          • Martin Vyšný

            Try http://www.vaadinonkotlin.eu – I am avoiding spring on purpose there :)

          • http://kyleharrison.ca/ Kyle Harrison

            Yes, http://sparkjava.com/ I now even have a full microservice powered by Spark2 w/ Kotlin out in prod handling tens of thousands of requests per day :)

      • golfman484

        That is the unfortunate legacy that Spring has rendered on the nice pure, simple, type safe, high performance language that Java is and always will be.

        IMHO Spring makes Java impure, low performance and removes any sense of simplicity with so much behind the scenes magic that is achieved with resource zapping package scanning and run time reflection.

        Because Spring has so infiltrated the Java world any newcomer to Java assumes that Java and Spring are one and the same and thinks nah, too complex, I’ll choose language X instead because I don’t have to worry about the crazy learning curve of all that Spring stuff.

        I see this as a huge injustice to the Java language itself as Spring, due to its wide adoption by people who follow trends like a member of a religious cult, rather than making decisions based on rational thought processes, have tarnished Java’s image but I’m finally seeing signs that people are realizing that you can go back to simple, high performance (no reflection, no auto wiring magic, no adding 70MB of size to your apps war file), enterprise grade application development in pure Java without Spring: “Stone the heretic!!!!”

        If I made this statement 5 years ago it would start a flame war by the Spring faithful who throw stones at anyone who decides not to follow the religion that they regard as “compulsory” for anyone in the Java world.

    • Brutus

      This also is how Django works, just half the time, you don’t have a stack trace to the actual problem in your code, but rather, to the place where the exception occurred in the Django code. Beyond useless – along with the fact there are type errors popping up everywhere and the documentation is absolute shit.

      • JorgeM

        Thats the reason I left my former job as a Python (Django) developer. The stack traces were beyond useless. Metaprogramming? Good luck!

    • sarnobat

      You forgot “factory” in that laundry list of weird classes that Spring makes you use.

    • Mark C

      “It’s only magic when it actually works.”

      Yes. and I think that makes it in a way even more scary when it does work. I don’t want things that work by magic. I want things that work for reasons I perfectly well understand. If they work by magic, there’s no telling when they might stop working, or for reasons.

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

    • normanfung

      It’s just a lot of pretense.

  • 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).

          • L’Huomo

            It is unlikely that they would ever find sanity. It would mean, they have to declare Spring as a false direction and stop its “development”.

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

          • L’Huomo

            I don’t believe you – you wouldn’t ever survive 10 years in a corporate environment writing “i” in lowercase. I think, you are a functional illiterate and a liar.

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

        • golfman484

          Some idiots in charge where I work drank the Angular JS Cool Aid a few years back. They’re stuck on Angular JS 1.x because 2.x was completely not backwards compatible so their entire UI is now tech debt.

          What can you expect with architects who choose technologies based on decisions based solely on what technology happens to be “flavor of the month?

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

        • Anatoly

          1. I bet no one really spend 2/3 of his time to write boiler plate code. That’s poetry
          2. Real amount of such code, we really do write every day, doesn’t affect personal performance nor total project cost. Almost all researches/papers/books state that syntax/language/its expressiveness doesn’t correlate to time to deliver

          So, what is the question is still a question from pragmatic/professional point of view

          • Thomson

            It takes 30 minutes to write a complete functional REST service (embedded Tomcat and if you like packed in a Docker Container) which retrieves Data from whatever Database with Spring Boot. It takes about 2 minutes to change your backend from e.g. MySQL to Mongo DB or Elastic Search.

            I seriously doubt you can do this without spring

          • Anatoly

            Yeah, I see. This is, of course, typical but useless argument. I can imagine a project which goal is: to write SOME prototype ASAP (performance doesn’t matter, features doesn’t matter, bug fixixing/extendibility doesn’t matter, number of 3rd party dependencies doesn’t matter etc.etc.etc.) and drop it out and forget. Or a project which requires to change backend twice a week. But I don’t know such ones in real life. No ONE. Your hour (30 mins + 2 mins +…) costs nothing because it gives nothing in real life projects with life cycle in years. This is ridiculous, sorry.

          • Thomson

            Uh… we have this stuff in production for a website that has hundreds of thousands of PIs per day.

            We use different tools for different jobs. Spring is not good for everything but for some tasks IMO it is brilliant.

            Btw I am working there at senior developer for 15 years now, starting as one of 2 developers and now we are a team of 20.

            P.S: We removed spring from one of our core applications because it was not stable enough, so I know where some people are coming from. But I think as everywhere else, the world of Software Development is not black and white.

          • Anatoly

            IMO, almost all can work. Somehow. Somewhere. I remember the good old days people used to use Entity JavaBeans to have an abstraction over the storage. With Statefull JavaBeans above and Servlets and then JSP on the top (I have counted 5 levels including the storage – typically a rdbms). And almost all was configured with XML :) It worked somehow somewhere. Another people paid for such type of “engineering”. All of that was really crazy :)

            >But I think as everywhere else, the world of Software Development is not black and white.

            Great point. Sorry if I was too white or too black:) I work in fin-tech (also as a senior) for years and I’m a bit crazy about performance. Maybe too crazy :) For example. For REST/Websocket API server I prefer to use Netty (or Jetty) directly. If I do have almost stateless API server and my state is the storage (relation or nosql), I’m trying to don’t instantiate thousands of objects just to build a few JSON strings (btw, with iterating over the same data twice: JDBC->collection of Hibernate DV objects + collection of these objects->JSON). I just iterate once over the query’s result once to fill-in a buffer with JSON to send it out. We even prefer to use streaming oriented JSON parsing if possible rather than object binding (this is like difference between DOM/JAXB and SAX/StAX). Also, I’m personally a bit crazy about number of 3rd party dependencies. I prefer simplicity/evidence over expressiveness and so on… Such priorities just don’t allow me to be happy with Spring and its magic. Of course, different people/projects have different priorities and motivation

          • golfman484

            “I seriously doubt you can do this without spring”

            The trouble with Spring people is this type of attitude – to them it’s like no other framework, tool or library in the world, ever, could understood or implement the concept of abstraction. It’s just so foreign to the mind of a Spring evangelist that ‘abstraction’ is not a concept patented by Spring and it existed well before Spring and will exist well after.

            To demonstrate abstraction exists outside Spring in relation to the database example you give:

            – DataNucleus ORM with no Spring dependencies: With an app written with JPA or JDO – you can switch between many of the SQL, NoSQL, graph, network, object database and document datastores it supports in under 2 minutes.

            – If you’re happy to stick with SQL DBs only then, for an app written with JPA, then Hibernate ORM will switch between different SQL DBs in two minutes – all without requiring Spring.

          • Martin Vyšný

            Challenge accepted! Done in 10 minutes using Kotlin, vok-orm and RestEASY. https://youtu.be/bvVB5WgCEyA

          • golfman484

            I agree – it’s like those people who say “language X is so much better than language Y because it’s string manipulation is so cool” – I say “well whoopty do!” If those people think that productivity as a developer comes down to how quickly you can write code to manipulate strings then either they’re not working on the same types of projects as me or they’ve completely missed the point of good software design.

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

        • Anatoly

          > just concentrate on your application logic.

          Maybe that’s the difference. If I use Spring, my application/my product is the whole of that stuff, including a lot of 3rd parties deps, which may be unnecessary for my specific business logic. I’m sure you have seen typical Spring stack-trace. Such trace means I spend hundreds of thousand of CPU cycles on abstractness per 1-10 cycles of business logic. For me, this is like I have build a car for my client and the car eats 100K litters of gas per 1Km. So, the question is who I am? Am I a highly qualified engineer or “application logic monkey”/typical low qualified outsourcer?

          >the boiler plate code…
          IMO, “the boiler plate code” specifically is a psychological problem and it doesn’t affect time to deliver or any other metric of typical project with typical life cycle 2-N years. But a tool you have introduced to fix that psychological problem may affect :)

          • Thomson

            Well… after spending hours of writing read and write and readFields Methods to implement hadoop Writable and having to make sure these things are backward compatible to old data I think it is not just a psychological problem.

            However, I would never do big data with spring for exactly the reasons you stated.

            On the other hand, whenever you are in the protoyping stage or for internal convenience applications which have no real performance requirements I think it is brilliant.

            It can work in production, but I must admit my enthusiasm for it has also lowered a lot since I started using it.

      • mirak

        You can use Google Juice which is lighter than Spring, but with the same principles.

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

    • finalfantasyguru87

      You can exclude dependencies and classes you need.

      • Brett Ryan

        Sure, but the point is with spring framework it’s easier to opt in, you have control, you know what’s going on. With boot you have to know what to turn off, and for the most part all of boots “sane defaults” are not documented.

        I don’t debate boot doesn’t have a purpose, pivotal should just stop pushing it on us and support using spring framework, many are just giving up on spring and opting for JEE

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

    • sarnobat

      Those people who like spring are the ones who no longer have to write a line of code themselves

      • fatty

        I’m a manager, and I hate spring. Every single one of my devs love it, and I’m having a hard time getting rid of it.

  • 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).

    • Erick

      Which one did you choose?

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

    • golfman484

      Yes, I noticed that too. When debugging a Spring “powered” app, single stepping through function calls takes you 37 calls deep into “stinky, smelly proxy crud” so much so that most of the time you give up because you’re wondering when the pain will end and the debugger will finally end up executing some code that was “ACTUALLY WRITTEN BY ME OR SOMEONE I WORK WITH”.
      I’m a contractor and I work on clients apps with Spring and many without Spring – the ones without Spring are always a dream to write, debug and generally work with and understand. The ones with Spring …. not so much :)
      Does any Spring evangelist just for ONE MINUTE consider the performance cost of burdening and CPU with having to make those 37 calls through the “proxy swamp” each time I want to execute some of my code?
      Most developers who have been using Spring their whole development career probably have no idea how fast Java apps can actually run when they aren’t burdened by the proxy/reflection swamp – but please don’t tell them because they’re probably working for my competitors :)

      • Peter Vaňušanik

        useless drivel, there are no 37 “proxy” steps, mostly 5 proxy calls for session-beans and that is all, why are you so negative?

        • golfman484

          It’s not useless drivel at all: It’s very helpful to any newbie who thinks that, be regarded as a “professional” Java developer, they need to be burdening otherwise pure and easy to understand apps with all these extra performance draining, obfuscating, over the top BS framework elements to do things that you can easily very minimal pure Java code. The only reason Spring still exists today is due to people who like you trying inflict FOMO on those who choose to write Java apps the way they were meant to be written: clean, easy to understand and highly performant. No wonder newbies are scared off Java these days because they have been convinced that Spring is somehow part of Java and must always go hand in hand with it.

          I have never seen an application get faster by “Springerizing” it, in fact quite the opposite has happened whenever anyone I’ve worked with has had the “we must add Spring” brain fart.

          The stack traces I’ve followed in many of our springified apps show stack depths with org.spring* of much greater depths than 5. Ok, not quite ’37’ but waaaay more than 5. In iterations spanning hundreds of thousands of objects in a large collection even an 5 extra calls into stuff that’s not my core solution code in what is meant to be a very tight, efficient loop, is extremely unwelcome – unless, like many others you believe that the cloud makes writing really inefficient code viable because you can scale infinitely (but just don’t mention that infinite scalability in the cloud comes within infinite cost – a fact overlooked by many)

          • Peter Vaňušanik

            well we use it to develop web applications and time to retrieve data from database takes longer than couple cycles in constructor and/or proxies. I fail to see the problem.

            Also, any IoT will make your application slower. The trade off is that it makes it easy to change the configuration at any time. If we followed your advice about speed, maybe we should only program in assembly instead of high level languages, speed will be amazing, but programming ease, maintainability and reuse-ability is what counts more than raw speed…

          • golfman484

            Our experience show that Spring’s obfuscating magic is usually way more than a ‘couple of extra cycles’ – obviously when you observe your stack trace frequently being waist deep in many levels of org.spring* proxy/IOC/AOP method calls it’s clearly evident that your CPU is consuming waaaaay more than just a ‘couple of extra cycles’ to perform the ‘behind the scenes magic show’.

            I’m not sure how my advice about avoiding the speed degradation caused by the use of Spring leads you to the conclusion that we should be writing apps in assembly. All I’m saying is just don’t use Spring if you want your Java apps to run optimally – pure Java with HotSpot/JIT optimization produces extremely optimal assembler – no need to go crazy and write the assembler yourself :)

            The big picture problem is that many devs drink the Cool Aid of a framework and think they can switch their brains off as they follow the other sheeple – without consideration of performance or what it’s actually doing behind the scenes. Most would be shocked.

            It’s a bit like how many users treat Hibernate – they put it on their resume and you assume they know how to use it properly. Don’t get me started on Hibernate… 😉

            Well ok… I was speaking to a lead dev about performance issues in an Spring/Hibernate web app we’re working on. One entity that’s constantly being loaded from the DB has a large BLOB field. The field was marked as LAZY fetched but he was clueless as to why it was still slow. When I told him Hibernate silently ignored LAZY annotations on attributes he looked at me as if I had two heads. “Really?” – yep unless you enable byte code enhancement – to which he responded “what’s byte code enhancement?” – This explains my point exactly.

            Then I revealed to him that there are other, superior but less popular, ORMs which mandate byte code enhancement because it’s far more runtime efficient and gives much higher developer productivity because you never have to deal with “slings and arrows” of an underlying proxy implementation and his response was – “Are there ORMs other than Hibernate?”.

            The IT world is full of uninformed, intellectually lazy people who much prefer “fitting in” unnoticed than thinking for themselves – and I bet most of those people use Spring and Hibernate 😉

          • Peter Vaňušanik

            your examples are great and all, but I fail to see the point. We are using spring because it allows us to configure our applications at runtime without redeploying by simply changing the configuration. Also, it allows us to simply change the configuration and alter complete business logic. Simply change the bean and all classes that use the bean will behave differently now. We also use aspects to get rid of even more boilerplate code and use @Configurable/@Autowired to get everything set up. Really couple cycles that will fill those autowired fields with beans is much better than hardwiring everything…

          • golfman484

            It sounds like you’ve never built a dynamically configured application without Spring before.

            And right there is the myth perpetuated by all Spring evangelists – “If you’re not using Spring you therefore must be hard coding everything. How could anyone possibly have dynamically configured apps without Spring?”

            Spring has become a crutch for the masses – the types who are too scared to think outside the box.

            Anyone who thinks they can’t do dynamic config without Spring must be a very incapable Java developer. It’s one of the first skills good Java devs learn. It’s not the sole domain of Spring although many have been hoodwinked into believing that.

            The GOF provided all the necessary patterns (Template pattern a biggy for interface/impl dynamic ‘plugin’ behaviours for any app) for dynamic config well before Spring was even thought of back in the days of C++. Then Java made it very easy and simple to build highly performant dynamically configured implementation behaviours and configure them via simple property files (not XML and no need for annotations – just simple POJOs – the way it used to be when Java apps were simple, fast and easily understood) without all the startup and runtime tax Spring places on an app.

            The marketing coup of the century was Spring convincing sheeple that they couldn’t possibly attempt such trivial config implementations without:
            1. In the early days, a repulsively ugly set of type unsafe XML Spring bean config files – my faith in Java developers was lost when many jumped over the cliff an adopted this like it was manor from the Gods.
            2. Later on, realizing how repulsively ugly solution 1 was, a new version brought a repulsive set of Spring bean annotations littered throughout your code making it completely implementation non specific, unless you want your app to not scan the entire jar universe at start up by you telling it a specific package to scan. It also brought the dreaded and hard to debug ‘auto wiring’ failures.

            The first wave was laughable as an elegant solution to implementation provisioning and the second was a major joke. The premise is “we don’t want to specify a particular implementation of an interface in the code” – fair enough but, if you want a large app with many dependencies to start up in a reasonable time you have to avoid a wide ranging component scan and basically specify a specific package in which to scan for a viable implementation of the interface – funny!

            It’s like saying “I’m not telling you what implementation to use because that would be hard coding the implementation but between you and me, don’t look anywhere else for the implementation except in THIS EXACT PACKAGE!”. How is that not equated to “embedding implementation specifics in the code base”?

            People eat this dog food on a daily basis without question and it’s an endless source of entertainment for me 😉

            I’m not saying these things as an uninformed, novice Spring user throwing abuse over the fence – I’ve been working on a Spring based app for 3 years now – and know how to use it proficiently – but I’ve reached the conclusion that for all of the trouble it puts you through and all of the slow start up time (= lower dev productivity) and runtime taxes it places on your app for the couple of lines of typesafe Java code it replaces – IMHO the pay off just isn’t there. That’s my observation as a user of Spring.

          • golfman484

            I replied to this but the response got moderated apparently. So much for free speech…

          • Madhavrao Peshwa

            Spring introduces employment problem also. Spring advocates say “Avoid boiler plate code and focus on business logic.. Heavy lifting will be done by us(spring libraries). But when you appear for the interview, you will be asked “How Spring XYZ framework works etc” You can’t get away by saying – I focused on business logic..”!

          • Tony Weston

            I dont use ORM. Its too dangerous, for exactly the reasons you said. I had no idea about byte code enhancement needed to enable lazy annotation…. but why should I?

            I use JDBI and raw SQL for all my database accesses – I know im not going to shoot myself in the foot due to lack of knowlege then.

          • golfman484

            “I had no idea about byte code enhancement needed to enable lazy annotation [in Hibernate]…. but why should I?”

            I agree – and in proper ORMs you don’t have to worry about things silently not working at all and other things working but not efficiently without byte code enhancement:

            It’s not an option, it’s mandatory in proper ORMs because the developers of proper ORMs don’t spend almost a decade spreading FUD about “the evils of byte code enhancement” (only to later implement it themselves) because they know that without it you’re setting people up with a lifetime of performance issues on anything but trivial object graphs, workarounds, caveats and silently ignoring their annotated wishes.

            The good thing is that if your code was written using JPA then you should be able to easily replace your current ORM with another JPA compliant ORM whose developers acknowledged the importance of byte code enhancement from day one, like DataNucleus which I switched to after being bitten too many times by the one most people seem to use (but have no idea about how it works under the hood),

            I haven’t heard of JDBI but I’m happy to stick to the ORM world as we have very large, naturally expressive, serious OO models (definitely not anemic models) and we do experience massive productivity by virtually transparently persisting them with a proper ORM. I would hate to do the Object Relational Mapping of those models myself so I would be very hesitant to let go of the ORM world.

  • 范国刚

    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.

    • Aluan Haddad

      Writing XML isn’t that bad. Reading XML is that bad.

      • finalfantasyguru87


    • Mike Thomas

      Neither reading XML, nor writing it, is that bad when it comes down to it. There has been WAY too much whining about XML IMO. If you use a good Java IDE (like IntelliJ), then your Spring configs can be autocompleted and validated magically, with tools from freaking more than 10 years ago.

      I worked in a 500k+ LOC financial platform for many years using Spring 2 and 3 with Spring MVC for the UI. Probably 250 or so controllers. Big – admittedly too big – app that was the platform for the entire organization, both internal and external.

      External XML configuration allowed us to build pluggable components (UI and back-end) that could be wired together explicitly to make different assemblies from common parts via DI. Hell we had a “document engine” that was configured in Spring. You could introduce a new document, or even compose different documents into a new one by editing the XML. Nearly foolproof.

      Unit testing was easy, and integration issues were almost always immediately evident, easy to fix, and were unlikely to revert. The system was modularized (80 modules when I left), and very maintainable and malleable.

      All the senseless whining about XML has led to more pervasive use of annotations and auto wiring in Spring and everywhere else, which is not an improvement, IMO.

      More generally, I’m not sure what people hate so much about Spring. Maybe it’s the first thing they ever saw and didn’t wade through the typical J2EE implementations that preceded it. Nothing I’ve read here is very convincing as a counter argument to Spring. Mostly just whining and “I’m too smart to need it”.

      It certainly didn’t punish me as a developer, or the financial services company, as a beneficiary, which is *still* running, and *making money*, on that code built using Spring.

  • Lúthien

    When I started with Java around ’98 it was just Java, and all was well.
    But it wasn’t long before the enterprise editions/abstractions/frameworks came creeping in. I remember the Sun Java event in Rotterdam where, during a presentation about SOAP or UDDI (or something like that) where I first got the feeling that something had entered java programming that was, well, not programming – but something entirely different.

    The common factor among all frameworks that annoys me is not that they force a certain design, architecture or adopting certain formats, but that they take part of your work away and replace that with something that can never be understood in terms of what you already know (ie. Java itself). And oftentimes, it cannot even be really understood if you do go to a course covering that framework, and have the 1000-page “framework-X unleashed” book on your desk.

    At times, the situation can be uncannily like practicing some kind of occult ritual, where you just need to sing the right incantations during full moon, and the thing works, though why it works remains elusive.

    I should stress that I did not just simply reject it because I didn’t like that kind of magic. Actually, I do like magic a lot – but just not in something as rational as programming.
    I certainly seem to dislike frameworks a lot more than any colleague I have had since then, so I guess part of it is that I’m just not the type of programmer who likes to use frameworks. I like to *see* what happens, just as I’ve always wanted to know how things work myself instead of ‘leaving that to the experts’.

    And another reason why I dislike it is that I don’t like the way proponents of using certain frameworks always seem to resort to the same tactic of calling those who disagree with them either dumb because they don’t understand it, or dumb because they are so stubborn because they want to re-invent the wheel time and again. Well, maybe it does pay off to learn a bit about wheel-inventing, because outfitting each and every car, train, bicycle and truck with the same CircularRollingTransportationDeviceFactoryFramework might not be the best solution after all.

  • Eugene Nikolaev

    I’d like to complement the theme with a pair of articles of Yegor Bugaenko (yegor256).


  • Alberico Durante

    I love developing apps with wffweb https://webfirmframework.github.io/ instead of Spring because we can write everything in java instead of html and other stuffs. It also handles all server client communication, ui updates and all. For me, I’m never going to modify the html/css/js file once the war is built. So writing everything in Java instead of html/js etc.. seemed to be perfectly fine for me. IMO, there are many good frameworks out there but the spring just got highlighted because of its enterprise level modules’ availability. Most of the companies asking the experience in spring, may be because they have already done their project with spring and not planning to port the entire project to any other better framework, there are lots of developers available with spring experience. I know some companies are also using the customized version of spring. I have also used vaadin before wffweb. vaadin is also good to develop single page business application and can write everything in java and no need to handle any server calls/rest service etc… vaadin is dependent on other frameworks but wffweb is a single independent jar. The sad thing about wffweb is they haven’t announced a stable final version yet. So I think, all frameworks may have its own demerit once they are used in the requirements.

  • Paul Ackley

    How funny and true… thanks!

  • Little Rascal

    Well said. Spring is overly engineered crap. The very essence of java is totally lost with time. In the spring worl all we do do wire them using either xml of annotation. At times it gets so so difficult to even debug the spring app.

  • mirak

    I like Spring, and don’t know springboot much, and laughed with the inception joke, a framework for a framework hahaha, good one.

    But really when you work on legacy shit code, you are happy to replace the old un-maintained crappy in house framework by Spring.

  • L’Huomo

    Spring was developed to make work, and not for to make solutions.

    I.e. the goal of the spring to guarantee that no one will ever be able to continue or even understand that project.

  • Kai

    Googled with “spring mvc is very heavy” and now I am here. This article helps me release my anxiety on understanding the conventions of Spring, and stepping back to review this framework.
    The conventions are just there, so I tell myself just relax and take time to get used to it :)

  • http://casagrandeusa.com Mark Paul Casagrande

    Great job, well written, and says it all. There’s only so much more i want to have to memorize in order to program successfully, especially for my own purposes, not for an employer. Also, it’s an important and powerful aspect of the paradigm, that it comes from a former devotee and evangelist, one who was proselytizing the usage of Spring by himself to power the injection of values within his own applications.
    There is something masochistic about this level of implementation of framework usage that is only explainable by the the Adonis complex (look how handsome it is). This is also the explanation for a lot of CS concepts gone wild. Not everything that ever came out of a CS program was meant to gain popular adoption. This is too commonly forgotten these days. It;s one thing to publish or perish, another to take it too seriously. As far as Spring goes, config or .ini files, or a database config table are all most of us need. And even those need a hell of a lot of comment lines in them :-)

  • VulcanTheTerrible

    I work at a place with a mixture of Java Spring Boot and C++ apps. The spring boot apps typically take like 4-5 Gb of RAM, 5-6 minutes to start up, and are slow as molasses. The C++ apps take on average about 200 Mb, take a couple of seconds to start up, and service requests on the scale of microseconds. Granted its never an apple to apple comparison but I find it hard to believe that an app that communicates with service discovery and makes a few REST calls needs 5 effing Gb to run (the C++ apps do more or less the same thing in addition to being realtime media streaming servers)

  • Anatoly

    Absolutely. Spring is about anything else but definitely not about programming. My personal typical use case is to check their sources/dependencies to see what proven libs they wrap and use something like jetty websocket/REST server directly with all options/features available without all of that useless and hardly manageable magic

  • Manuel Tijerino

    I always have hated and still do hate Spring, I see Spring as boilerplate code. How many methods do you really need to run a query through JDBC? I only need 1. Select * from bla bla bla result set metadata list of maps and done no need for Spring. How about to create an XML rest service? for int i bla bla bla bean.toXML. How about json bean.toJson, if an organization is using Spring I refuse to work for them plain and simple.

  • sarnobat

    Configuration instead of code fallacy

    Framework designers think that they can save you the impossible job of writing code by instead asking you to specify runtime configuration (i.e. code declaratively/configuratively) for your app’s behavior.

    The trouble is, that configuration is almost as long as the code it is intended to replace (at least, if you want to create a meaningful application). But unlike with code, there is no compile-time checking for configuration (by definition; if it did have compile time checking, it would not be declarative. It would simply be a different programming language). You will only find that something is wrong when you attempt to run the application and it blows up in your face.

    I know how to write code thank you very much. To the designers of any framework: your desire to get rich and famous by having us masses follow your lead is, for lack of a better description, delusions of grandeur.

  • Tom Tracy

    I don`t know spring. but apache tiles sucks.

  • Edoardo

    Sorry but I disagree. Spring has a step learning curve? No, you just can’t start writing code before you understood how it impact the global state. The Spring documentation is clear, well written and modularized in different compartments. If you guys are lazy that’s not a Spring fault. Still now I face problems sometimes, but it’s my fault, I’ve not read the documentation properly. You guys think it’s possible to manage an enterprise application with millions of classes without reflection? Without bytecode generation at compile or Runtime? I’m scared to see your code base. Spring provides a way to layer your application without much hard work, it’s basically bootstrapped, and Im not talking about Boot, I’m talking about the use of different modules together. You had the wrong version of a module? Your fault. You auto wire everything and generate a circular dependency? Your fault. You see, there are many “your fault”. Spring is not magic and it’s perfectly debuggable. You dont know how to debug and log problerly with Spring? Your fault. I better stop here, as I’m tired of lazy developers who just want to “write” code (don’t take this as an offense)

  • Zack Macomber

    Spring is powerful and wonderful in a lot of ways but really where we all are failing as developers is we’re not concerned with the design of our applications as much as we are just coding stuff. That’s really what all frameworks do – they provide the design of our applications. Maybe it’s a bad comparison, but who builds a solid house (application) without building plans and architecture (application design) set up first? Developers should spend more time learning application design principles and then maybe we wouldn’t have the myriad of frameworks we have. I believe that with a rock solid application design the coding should be fairly straight forward and have very little head-scratching/head-banging moments and the need for a framework goes away.

  • Jiří Kačírek

    This is very nice place to show your anger to Spring!

    I just spent entire day trying to deploy Spring Boot Starter at provided Tomcat. The problem is that I was unable to update even some .html file – any life reload happened. After several hours of fighting I have found that Spring devtools are magically inactive when you run Spring in container, as it magically suppose its fucking production build!!! Fucking magical bitches. Last time I have spent 2 days of tryings to make JSP files working instead of default Thymeleaf!! Without success, any fucking example or advice was working.

    I’m not surprise that Spring is using mainly in corporates. I can’t imagine spent so much time stucked with Spring as freelancer. I’m very sad for this as I like Java but in the future I will have to possibly migrate to some another technology. This complexity and unpredictability and magicness is absolutely unacceptable and it pissed me off so many times :-(

  • Marcos T Pires

    Good lord finally I found someone who thinks like that. I am a new developer at Spring, been doing java for quite some time but spring is a new, horrible, experience. I was starting to think I am crazy for not liking it, because everybody else does. Thank you for restoring my sanity, now back to make that stupid bean wire properly

  • Sergii

    You just getting older :)

  • normanfung

    hate Spring dude. In fact I hate most DI framework. All I really need I just libraries that does things for me, not to offer me learning curve and nothing in return. Spring is just bad waste of time, all hype and pretense. Python DataFrame is opposite: It work for me! Not the other way around. It’s ridiculous how academic software development community had become, all the pretense, self proclaimed righteousness, almost religious just waste of everyone time achieve nothing. (Just make couple constructor overrides and your thing is testable, stupid)

  • gekaprog

    Yes, Spring is overblown and can drive you up the wall. Anyone who defends it has not been in a typical large organization (bank/software company) where a number of people touched the code, left the firm, tried Google Juice, Dagger, custom properties. While they did not have a perfect knowledge, Spring itself kept changed. So your application has as many XML files as it has classes. You start to wonder where the logic is and shouldn’t you be unit testing XML configs.

    Once you work on somebody else Spring-ed app, spend hours or days figuring out XML files, relative order, overrides that make up the app. Then you find out middle of the day that your application is actually misconfigured cause bean X was supposed to be Y or you just can’t start the app.

  • Werner Vogelweide

    Dudes! I just wanted to say “thank you” for this article and for all the supporting comments. This really helped me a lot to get over a bad day with being forced to use this Spring and Spring Boot stuff whether I like it or not. In software development people just seem to be crazy about jumping on anything new that comes along and creates a stimulus on their minds.

    I think it was a design mistake back then by Sun to allow for those byte code manipulation gimmicks. Once you open the door for that kind of things some folks will inevitably jump on it and some other folks will run after it.