• Guice and Spring
• Declarative transactions and JTA
• EDA, Pipelines and CEP
• SOA and ESB and NMR
• Column databases and distributed file systems
• Wicket and various related Ajax components
• OSGi in various permutations with the above
• BI, in-memory BI and CEP (again)
• AOP and/or IoC patterns

And now I’m contemplating the fultility of programming.

Introduction
I’m afraid I don’t “get” it either. Religion does that to me, as soon as someone tells me if I would only get it I would understand, I automatically back off, ready to fight. I mean, if I only would let Jesus into my life I would start believe, right? And if I would only start getting Spring I would be a follower too, right?

Yeah, right.

You don’t think it is a religion? Well, try critizising it, and then check what kind of responses you’ll get. (In fact, have you read a critical analyzis of spring at all? Probably not, I know that I haven’t. And that worries me, and apparently Crazy Bob as well, a bit). Or you can read Bobs post and then scan through the comments:

• “I use it and it works for me”
• “If you just get it you would understand”
• “So? Don’t use it then”

And many will testify to the fervor with which Spring advocates jumps at any doubting voice. (Also among the comments, there’s some long sales pitches from Keith from the Spring Web Flow team.)

So why am I sceptical? Well, the religion issue apart, here’s some things about Spring which I question:

• It is not very a light-weight sollution
• Spring does affect you code
• There’s no clear demarcation between code and XML
• Spring XML effectively is another language
• Refactoring and debugging becomes a pain

Let’s take them on, shall we?

Heavy Ball and Chain
Light-weight? Erhm, no, I don’t think so. Light-weight in my book means small, non-intrusive and without any particular runtime impact. Also, I don’t expect light-weight sollutions to have any significant impact on my coding style. And let’s not forget what Bob points out, the public contracts of Spring are very much not light at all (but to their defence, they do have extensive API documentation provided).

Don’t Touch My Code
Contrary to claims, spring does “touch” my code. Just becasuse what injects your dependencies on the right places sits outside your code instead of within it, doesn’t mean it doesn’t exist. I mean, how do you start you application? It is correct that no Java code is visible in your project, but this is not necesserally a good thing. And as Bob puts it:

Spring advocates tout that Spring doesn’t “touch” your code, i.e. you don’t have to implement any Spring-specific interfaces (with the exception of life-cycle interfaces, etc.). News flash: the XML configuration *is my code*, and from what I can see it often ends up constituting a lot of code, all of which is Spring-specific. 

Demarcation
Where do you draw the line between Spring and Java? If you do it too coarse-grained you don’t particulary need Spring at all, but as you penetrate deeper the amount of XML will grow rapidly, and that will soon become a problem. I have been in projects with fully grown “XML Hell” problems. It. Is. Not. Funny.

Mixing Langauges?
Please read the Bob-qoute a few paragraphs above: XML is code in a Spring project. A “fully Springified” project will most probably, thanks to the demarcation problem, have a lot of XML files in a 3rd party language. In other words, in order to fully understand, and therefore effectively work in, such a project you need to be fluent in Spring. Light-weight? No. Does it affect my code? Yes.

Do I really want projects written in two separate lagauges? Perhaps it isn’t a problem, but you must understand that when you take the Spring step, you are forever relying on dual-language programmers to work on and support it. And large projects tend to live longer than their programmers. That might be a really big problem for any Spring project in the near future. Seriously. What if you can’t find any good Spring programmers to hire? Legacy code is bad enough. Legacy code in an obscure XML language that no-one really uses any more is even worse.

Hard references and strong types
I like strong types. I like hard references. They make my life as a programmer so much simpler. And both of them are negatively affected by Spring. This problem will shrink a bit when IDE’s becomes better at handling Spring files for you. But right now, they’re not up to schratch.

Conclusion
Does this mean I don’t like dependency injection? Not at all. Good programmers do that all the time without the help of any heavy-weight framework. Does this mean I will never use Spring? Not at all. But I consider the above points very important and unless I’m wrong, which of course may well be the case, I’ll probably try to stay away. And to be very, very clear to any Spring zelaot happening to read this: Don’t bother to answer unless you have answers, they’re specific, and to the point. I’m not interested in your religion, I’m interested in writing damn good code.