I don't get Spring

Like CrazyBob, of guice fame, I also don't get Spring. Hammet also doesn't get it.
I mean what is the whole idea of wiring by xml? To decouple the wiring from the model.
But if you put the wiring.xml in the jar, so that it lands in the maven repository, to be used by others then it's not really decoupled.

Suppose I have 2 services, with their corresponding interfaces

class Producer implements IProducer { ... }
class Consumer implements IConsumer {
____Consumer(IProducer producer) { ... }
____...
}

what do we put in the xml file ? Basically we repeat the code-lines.
[bean id="..." class="Producer][/bean]
[bean id="..." class="Consumer"]
____[constructor-arg ref="..." index="0"/]
[/bean]

So not only we write again the required dependency, but we do it in xml so that we don't get
the benefit of refactoring (any changes due to renaming are lost).
I've intentionally left the ids unspecified. What should we put in there? The name of the class or the name of the interface?
- If we put the name of the class, then the Consumer-owner must know which class implements the IProducer interface, so a large part of the benefit of using interfaces is lost.
- If we put the name of the interface, in a declarative way, 'I am an IConsumer and I need an IProducer' then we have really duplicated the constructor line and the class declaration line in XML.

And now what about setter-injection. When I look at a class, I look at the interface it implements and what services it needs (in the constructor) to fulfill that contract. But Spring favors 'Setter Injection'.

The Spring team generally advocates the usage of setter injection, since a large number of constructor arguments can get unwieldy, especially when some properties are optional. The presence of setter methods also makes objects of that class amenable to being re-configured (or re-injected) at some later time (for management via JMX MBeans is a particularly compelling use case).

Constructor-injection is favored by some purists though (and with good reason). Supplying all of an object's dependencies means that that object is never returned to client (calling) code in a less than totally initialized state. The flip side is that the object becomes less amenable to re-configuration (or re-injection).

There is no hard and fast rule here. Use whatever type of DI makes the most sense for a particular class; sometimes, when dealing with third party classes to which you do not have the source, the choice will already have been made for you - a legacy class may not expose any setter methods, and so constructor injection will be the only type of DI available to you.

What does it mean for me, as a maintainer: I have to visually scan the file for the setters, wrap each of the private fields in a getter, and put in the getter a check for != null.

What about the argument that a class has too many args in constructor? Isn't that a smell which you should do something about it? (Well actually there are 2 smells: TwoMany-Parameters and ExpensiveSetUp)

What about the argument about 'optional arguments'. Isn't that a NullObject pattern?
So what was the Spring-solution? Autowiring? No, that came later. The Spring-developers said: we need an IDE to manage all that xml. WTF? Instead of getting rid of all that shit, you get a bigger shovel in order to dig deeper?

Now, the world is a little better. Now we have annotations and auto-wiring. But where are these annotations? Probably, declaratively, in a small component, so that other IoC containers could use these annotations for wiring? ... No, they are in the spring-core !!! (the logic is that if you were that smart/stupid to choose spring, then for sure you don't want to change your mind. And if you change your mind, than you should take every file and manually change the annotation and its import).

I really don't get the "significant benefits for many projects, increasing development productivity and runtime performance while improving test coverage and application quality".

ps. I had an argument about 'writing boiler-plate code isn't really that bad, since there are tools/IDEs to help you to write that'. I still strongly disagree: if 80% of the life of a software project is spend in maintenance, that means that we read/bug-fix code much more often then we write it. We must strive to READ LESS USELESS CODE.

pps. 'getter/setter methods are evil'

ppps. 'xml wiring is for girls'

ppps. from 'python is not java' : 'XML is not the answer. It is not even the question. To paraphrase Jamie Zawinski on regular expressions, "Some people, when confronted with a problem, think "I know, I'll use XML." Now they have two problems."'

ppps. A more detailed criticism on Spring.