1. They think Spring is XML
Complainers often blame the way Spring gets configured: through XML. They think the XML stinks, bloated and hard to maintain.

Quoting Spring’s Reference Manual, “XML-based metadata is by far the most commonly used... It is not however the only form… Spring IoC container itself is totally decoupled from the format in which this configuration metadata is actually written...”

Having thought that Spring is (configured solely in verbose) XML indicates lack of (albeit basic!) knowledge about the way Spring works or laziness to read documentation.

Spring 2.0 introduces XML Schema-based configuration which make XML configuration easier. It can also be configured using Annotation (Spring’s “official” style or the Spring Annotation project) or JavaConfig (programmatic configuration).

Not being aware with these options indicates unwillingness to catch up with things that may potentially increase their productivity.

2. They don’t know how to use tools to simplify their life
Spring IDE is a plug-in for Eclipse to make projects “Spring-aware”. It provides various features to make configuration less painful. It has strong type checking support (or something like that) so that you won’t type invalid classes or properties. It also participates in refactoring.

It is true that not everybody uses Eclipse. But Spring IDE is an open source effort; you can port it to another IDE if you like. AFAIK, IDEA also has Spring support to some degree. And hey, nobody uses Notepad for serious enterprise development.

Some of you might say, “Hey it’s cheating. You’re using tool! Spring XML sucks without it.” Well I would say, “The same with Java”.

Tools are made to help us, to make us more productive. Ignorance is status quo, and it doesn’t fit the spirit of software development.

3. They think all they need is a DI container
Some applications require no more than a DI container, most applications expect more. Sure, you feel macho when you (must) write integration code yourself. Not until you find yourself debugging your half-baked solution somewhere before deadline.

Spring is not just a DI container; it is a complete integration framework. You don’t have to use those integration features if you don’t need them, but you can rest assured that they are there when you do. Tested and proven.

Software development, especially as teamwork, is not for Superman. You will be respected when your work is brilliant, but if your ego hinders development (and causes more trouble than its worth), you’re out of the line.

4. They think application startup time is everything
Some people say that application using Spring is slower during startup. Well, I don’t restart my application every hour. Do you?

People complaining Spring startup time can be two things. They’re not used to (isolated) unit testing (so they have to start the whole application just to test a one line change) or they are too worried to small details.

Most applications don’t need to run blazingly fast, they just need to run in acceptable speed. Of course, being faster is a nice bonus, but it doesn’t worth the try if higher interest (such as maintainability) is to be sacrificed.

5. They complain, but don’t come up with a solution (or a better alternative)
If Spring doesn’t work for you, that’s fine. It’s not a perfect solution for everything and may be unsuitable in some cases.

Some people reacted by contributing code patches. Some others voluntarily become beta testers and give feedbacks to the developers. Constructive-minded people come up with solutions to enhance Spring’s limitation or even develop their own alternative.

Some people just complain. They whine in their blog, attacking obvious deficiencies with weak arguments, and do nothing to “fix” them other than creating controversy. There are even “groupies” who simply yell in virtually every thread attacking Spring.