All I really remember feeling when I first encountered Spring (in 2005) was confusion.  Hip leet Java hackers were gushing over it, and wanting to be seen as hip and leet myself, I wanted to be genuinely excited by it, but I just wasn’t.  Spring was designed from the start to be an IoC container, and IoC (while elegant) just isn’t excitement material, but that’s not the reason I was skeptical about Spring.  No, it was the highly touted silver bullet application of IoC called Dependency Injection that got me to thinking.

Specifically, thinking that I didn’t need it.

I’ve encountered a lot of problems with programming computers.  From my childhood hacking on Logo and BASIC on Apple ][s and Atari 400s to my professional life where I’ve done all kinds of crazy shit (I was even tasked once with installing an Oracle app suite onto a Sunfire server with one physical disk).  Along the way, I’ve encountered strange paradigms, nonexistent requirements, clueless users, impatient managers, cranky quirky tenured developers and their cranky quirky grandfathered-in piece-of-crap apps.  I’ve seen horrendous code, cryptic variable names, and surely-this-is-a-joke code snippets such as the following (yes, this was absolutely real):

if (val > 0 || val < 0)

(I guess someone really really wanted to set val equal to zero.)  Anyhoo, the point is, I’ve encountered a lot of problems in programming, and managing dependencies wasn’t among them.  Not once, not ever, do I recall thinking, “Damn!  There’s got to be a better way!”

Now, I’m not saying that IoC or DI are bad things.  They’re just unnecessary.  Nor am I saying there’s nothing to be concerned about whatsoever with dependency management.  It’s just not hard.  A Foo contains a Bar.  Foo instantiates a Bar and goes to town.  Most of the time, pushing that off to some framework seems like it’s more trouble than it’s worth.  The complexity hasn’t gone away, it’s just gone somewhere else.  When the framework requires lots of configuration via XML files, you’re most definitely robbing Peter to pay Paul.

“But wait!” say the enthusiasts.  “What if your implementation of Bar (gasp) changes? Dependency Injection is so helpful then.”  Right, because it encourages (though doesn’t demand) that you program against interfaces.  You could, I guess, do what every decent OO programmer has done (right…?) for the last decade and program to the interface as a general rule, but maybe that’s crazy talk.  Long story short: DI may very well solve a problem, but it’s a problem I’ve never had.

And it doesn’t solve it for free.  I’m not talking about any of those kvetchy cost-based objections to Spring like “it’s slow” (it isn’t) or “it takes too long to start up” (yeah, kinda, but how often are you restarting your app, man?) or (my favorite) “it takes up too much memory”.  No, I’m just saying that it’s one more chunk o’ expertise you need in your toolkit.  You need to be familiar not just with Java and J2EE and Tomcat and Struts and Hibernate and JBoss and Drools and JNDI and EJB and JMX and MVC and SQL and the whole alphabet soup of XML technologies but now you need to know about Spring, too.  I’m most certainly not against knowing things.  I like knowing things.  But having to know arbitrary things gets a little tiresome.

For all that, I do use Spring.  One, it makes no sense to be willfully ignorant of a common technology.  Two, it’s convenient at this point, and that’s what I mostly use it for.  If I’m building a Java web app (something I do frequently) then Spring allows me easy access to Hibernate (with annotation support and transaction management) and Acegi.  Bada-bing, bada-boom, I can get the basics up in no time, and do it in essentially the same way so I have consistency across projects.  In the long term, it’s a net gain.  But the gain comes from all those other people who poured a ton of work into Spring integrations (making it a de facto standardized Java sub-stack) not the time I “save” via the wonders of dependency injection.