Ten common misconceptions about Spring?

You might have come across Steve Anglin’s article in defense of the Spring Framework seen many places around town recently. A lot of us should recall the time when Spring was first introduced as a lightweight aspirin to our JEE headaches. Few years down the line, how much simpler is the Java Enterprise application and what is the role Spring has played in remedying the complexity?

If we compare what was in EJB 2.0 times and today, yes, I believe things have improved. But let’s face it, it’s almost impossible to make things more unnecessarily complex than that. But looking outside the Java camp, I can’t help but be somewhat skeptical, to say the least, as to whether we’re on the right track at all.

On with discussing some of the misconceptions, because that is my intention here…

In regards to misconception number one about Spring not being lightweight: Spring’s primary goal is to enable lightweight development based on POJOs.. Ah, yes… Plain Ol’ Java Objects. Wired in XML which is not plain or Java at all. Complexity is not eliminated by pushing it out of the code into configuration files that are not native or natural to the programming language. It’s still there hidden behind another level of complexity. Spring is described as a comprehensive integration platform for other Java technologies. Most of those technologies are already pretty heavyweight. So the application does not become much simpler or lighter, more like glued together with declarative configurations in XML. And, no, Annotations do not make things much simpler, the way Xdoclet didn’t make things any better back in the day. If you disregarded the Xdoclet code, EJBs were not that far from being POJOs themselves. So I do hope Spring does not go down the Annotations path any time soon.

Quoting Steve again: For one thing, even simple applications typically require some enterprise services such as transactional database access. In my experience, even complex applications do not require transaction management the way Spring handles it. Also, what is it that is so difficult about transaction management that cannot be dealt with POJC (Plain Ol’ Java Code)? But let’s, for a moment, suppose transaction management is that difficult to deal with. Does the introduction of AOP make it less complex? No, because AOP is complex in its own right, so it’s just adding more complexity calories to the meal. You get your clean POJOs, yes, and then you proxy them, target them and declare their transactional behavior in XML. Again. And you’re not testing the transactional logic you define. At least not in an easy, natural manner.

One thing I like is programmatic transaction handling with Callbacks in Spring. That, in my opinion is clean and lightweight and a really nifty idea. It also takes about 10 lines of code to achieve without Spring Transaction Management…

Spring replaces Java Enterprise Edition. I wish… If this was the case, I probably wouldn’t be writing this right now.

For a large application, Spring’s XML can become a maintenance nightmare. Everyone knows this, everyone has thought how when the next project comes along we won’t fall into this trap and every time we fail. Spring can be forgiven for going XML the first time around, when everyone forgot to ask ‘why XML?’, but I think there are no excuses for the next version of Spring not supporting programmatic configuration.

If Spring aims at just being a cushion on the 10 Tone JEE hammer we bang our heads with, I’ll tell you what, it doesn’t hurt much less. I think the real problem lies in the fact that we need a framework, lightweight or not, to integrate other insanely complex frameworks to achieve tasks that are not as tough as they seem. So I don’t see that much injustice in complaining about something that doesn’t attack the problem with means to eliminate it instead of hiding it. It’s like miracle diet products. The bottom line is, if you don’t lay off those burgers, you won’t lose weight, no matter what the ad in the magazine says.

4 Responses to “Ten common misconceptions about Spring?”

  1. Gary Furash Says:

    What do you think about things like Rife and Grails (for groovy). It seems to me like the right direction…

  2. Jason Yip Says:

    “I think there are no excuses for the next version of Spring not supporting programmatic configuration.”

    Spring does support programmatic configuration. Having said that, I’ve never actually tried to do it so maybe there are gotchas I’m not aware of.

  3. George Malamidis Says:

    As far as I know, Spring does not officially support programmatic configuration, although it can be hacked fairly easily. Programmatic configuration for Spring context and bean factories is currently in the sandbox and has been there for months.

    I’d be very interested to know if anyone’s got more information on this.

  4. Gleb Says:

    I guess it’s the case when a tech is misused… as occures often when something becomes a buzz.
    btw, spring website/books do not contain enough examples of good practices… but, picocontainer site does! nice anti-patterns section.
    also, I don’t understand, why spring doesn’t enable autowiring by default… it really reduces silly “xml programming”