The Path to Zen

I Don’t Get “I Don’t Get Spring”

I was reading Bob Lee’s Spring bashing blog entry, and, while realizing how high the flaming index the article carries, being a long-time Spring advocate, felt that I had to respond.

Oh, and let me get this out of the way first, too - I mean no offense to Bob (I’m sure he is a good person).

Bob starts with:

… but frankly I haven’t been able to get my head around your framework. Even worse, I’ve noticed what I consider to be a dangerous and blind increase in the rate of Spring adoption. I’ve yet to read a critical article or book on Spring.

Well, what I don’t get is, how can one “get one’s head around” anything, if one doesn’t even bother to read on it first?

… Maybe Spring adoption is a knee-jerk reaction to J2EE. “J2EE is bad, and the Spring guys say their stuff is better, so Spring must be good.” It doesn’t work that way.

Maybe, but then maybe not.

Firstly, even though I can’t speak for the Spring Team, I don’t think Spring is targeted to replace J2EE. If Bob wouldn’t mind just taking a peek at the Spring forums, he most certainly would realize most questions asked there are about how to leverage Spring in a J2EE application.

Secondly, last time I checked, the Spring team and most of the Spring users live in a society where information flows freely, and in an industry where competition is hot. Rod Johnson et. al. can’t just hypnotize people into thinking Spring is good. So, it’s not like “The US is bad, and Kim Jung Il says he is better, so he must be good.” No, sir, it doesn’t work that way.

The Spring folks openly snub their noses at J2EE, but from what I can tell Spring isn’t exactly lightweight and simple either.

Would Bob mind giving a link to the above “nose snubbing?” As far as I know, the furthest Rod Johnson has gone so far is a book by him on “J2EE without EJB”. Can we agree that J2EE ≠ EJB?

The Javadocs are unnecessarily overwhelming. Does all of this really belong in a user API? At least J2EE cleanly separates API from implementation.

That’s because J2EE is an API, and doesn’t have any implementation to begin with. And I personally find Spring’s javadoc the best among the OSS projects I’ve ever worked with, and better than lots of commercial packages, too. Most of the javadoc does talk about the API from the user perspective - what the API does, what the usual usage patterns are, what the best practice would be, etc. Seldomly it gets a bit longwinding, but I for one am willing to live with that, rather than opening up the class description for DefaultDAOImpl and finding myself staring at “The default implementation of the DAO.”

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.

Valid point. The XML is indeed Spring-specific. But that doesn’t necessarily make the container agnostic on the Java code side meaningless. Following the same logic, the J2EE “standard” would be a phony, too, because when was the last time you deployed a serious enterprise application without having to supply files like weblogic-ejb.xml, or jboss.xml?

Back to dependencies on Spring APIs; don’t I have to call the container to create my first object (assuming the rest of the Spring-managed objects in the graph are injected)? I want some way to check that the object I’m requesting is the right type at compile time. I don’t want to cast. Ever.

Another valid point, albeit not very constructive - since Bob already admitted earlier that:

… I’m talking about Spring specifically, not dependency injection. I love dependency injection, and I follow the patterns every day. Good riddance to service locators!

Why don’t we ask Bob to tell us how to implement configurable DI without any casting? Also, I’d like to remind Bob that the same argument applies to all the reflection usage as well. Does Bob never use reflection, ever?

It bothers me that I have to reference Spring implementation classes in my XML configuration. I don’t care about the plumbing. In Spring’s defense, I’ve heard they have so more concise, domain-specific XML coming in 2.0, but I haven’t seen it yet. Why didn’t this come up sooner?

Nobody has to reference Spring implementation classes in the bean definitions. They are just implementations that are convenient to use. Feel free to write your own and plug them in.

And, yeah, sure, why didn’t <plug in your dream feature here> come up sooner?

What’s with auto-wiring? Does anyone actually use that, or is just another notch in the feature headboard?

I don’t use auto-wiring in production code, because I think it’s too automagic, but, from what I can tell on the forums, a lot of users don’t mind. And one very popular use of auto-wiring is in writing test cases. It helps easing a lot of pain from having to wiring up the dependencies explicitly.

Fortunately, simply adopting dependency injection design patterns gets you 90% of the way, further if you don’t need encouragement to do the right thing.

I wonder how Bob would implement meaningful (i.e. configurable) DI without making it another container that has all “these same problems.” Show us how you would go that “90% of the way”, would you, Bob?