Link Details

This framework "bashing" (author's words) is based on very weak logic. Spring is a modular framework. If the author had 15 dependency entries in his Maven POM, then he was apparently using a large variety of Spring features (way beyond dependency injection, which was the final conclusion of his article). The argument sounds like the Spring framework is bad because it gave him all those features he needed in his application. Wow, that's terrible. As for configuration files, I seldom write XML configuration files any more with Spring and prefer annotation-based configuration.

I documented my experiences with a project that started using Spring because of DI, where one thing lead to another and all of a sudden Spring had creeped into every corner (not by my hands). You can claim Spring IoC only requires 3 jars but the fact is that once you open the Spring can of worms, you need a mighty informed and disciplined set of developers NOT to draw in other stuff from the Spring umbrella. Hell, one of the members is even using a special IDE from SpringSource in order to do his stuff.

There's a disturbing lack of criticism around framework overload and the mental strain of having to make choices constantly. You just highlight one yourself, i.e. the issue of annotations vs. XML. I have no problem with people using Spring, if it solves their problems, perhaps they are simply smarter than I. For me however, it's not worth the trouble - pure and simply.

There's a *huge* amount of criticism around framework and making choices in the Java world; I'm not sure how you've missed it. The bloat of the Java ecosystem has been a rallying cry for alternatives for years.

Even when I *am* only using Spring for DI I use the Spring plugin for Eclipse or IntelliJ's--why wouldn't I? It makes navigation trivial. Using an IDE doesn't replace actual knowledge. And I'm hardly that informed, disciplined, or smart--the things I use Spring for it does very well. Sure, I *could* roll my own (and do sometimes), but... I'd rather not if I can help it.

If Spring "crept into every corner" maybe there was a *reason* it did.

Spring is not a perfect framework, but the "issues" you list in your blog post are vapid and nonsense. I happily use Spring with only a couple of JARs without needing Spring MVC, Security, etc.
Just because your and/or your team are sloppy with managing dependencies doesn't mean the framework sucks. Any tool/framework can be abused to produce "bad" software.
The Spring umbrella provides tools for everything under the sun, as you mentioned already. This can be a dual-edge sword: on one hand you get framework overload, on the other it provides a unified platform for most needs. In the Java world, there's a tool or framework for virtually everything - so you're going to have this problem if you use Spring or not. I prefer to have choices, rather than having no choices (even when the choice is to "roll your own").

Why dont you admit it that you think you are the universe and everyone should do what is easy for you

Hey, one thing is certain. On MY blog, I darn well please can write anything I want... even if it conflicts with other people's view of the world :)

This is a poorly argued article, if indeed you can call it an argument at all. He makes assertions without substantiation, there are no examples, and I really can't get a sense of what exactly he is complaining about. This is where code samples would help a great deal. Otherwise, there could be all kinds of reasons for his rant, which may or may not have anything to do with Spring's real weaknesses.

Did his team go nuts with AOP? Make gratuitous overuse of Spring APIs? Or perhaps the Spring artifacts he sees reflect legitimate use, meaning his project actually *needs* the code he sees. For example, there is nothing trivial about setting up a security framework, so

Maybe what is happening is that the blogger got thrown into a large, substantial project and feels overwhelmed by it all. Moreover, he faces a double whammy: a large, unfamiliar codebase AND an unfamiliar framework. He sees a lot of stuff from org.springframework, and pins the blame on Spring. The thing is, Spring can actually be helpful in this regard. APIs from the Spring ecosystem tend to share a common "philosophy" and idioms of use, tying together many disparate systems. Anyone familiar with Spring idioms will feel at home going from one large project to another. It is the blogger's unfamiliarity with Spring that is his problem here.

With DI, you declare "beans", so yes, you need the "beans" jar. You're working with a "contect", so yes, you need a "context" jar. Spring actually got much better with the modularity in version 3 (actually, probably 2.5). If you're not using Spring's jdbc support, and the jdbc jars get pulled in, you're probably doing something wrong.

AWESOME article , finally people have started to speak up against this monster, and they VOTED this article up too. Those who voted down must be using Spring so they blindly did that.

i had learnt Java in 1998, i didnt keep much but then in between i kept in touch and learnt Swing. But all hell broke loose when i wanted to replace ASP and ASP.net, i kept reading and reading and reading and it just never ended and when these people kept talking about spring hybernate maven, i just gave up.

Now i am keeping my fingers crossed with Scala, i waited for so long but Visual Studio still rules.

btw, now WTH is this Guice. When will we work if we keep on reading.

Guice is pretty old. It's type-safe DI/IoC, and if all you need is DI, it's a good solution.