Spring’s flaws

I love Spring Framework. I use it on almost every project and I’m pretty close to think that I couldn’t leave without it. However, lots of people really dislike it for plenty of reasons. This makes me wonder what are the real flaws I would name.

The first flaw that comes to my mind is the documentation.

Really? When giving training on Spring for Valtech, I’d always tell trainees that the documentation was very well done. In fact it is. But, it is pretty outdated. Not for its content but for the way it considers xml as the primary configuration paradigm all the way through (well, not for aspects).

Xml DSLs are verbose, lack serious static checking and, let’s be honest, XML wasn’t really made to do this kind of things.

Spring has been able to use other configuration paradigms (none, plain java, annotations, JavaConfig…) for a long time but this is very often considered secondary options.

Maybe Spring 3 will change this by sort of “deprecating” xml configuration. I’m just afraid that annotations will be the new primary configuration paradigm that we’ll complain about in the coming years.

Speaking about documentation, another flaw is the bias towards plain JavaBeans. Spring is really pushing a POJO approach but people understand pure JavaBeans. With default constructor, getters and setters…

This was not Spring’s original intent and, believe me it it still very powerful in integrating frameworks not based on JavaBeans (ever tried Joram?). But reading the documentation, the borders between POJO (ie. any Java object that you can write) and JavaBeans (overused silly reflectable properties wrappers) tend to blur. Why did they use the name Spring beans? I think it was to show the lightweight approach compared to Enterprise Java Beans. But now that EJBs are dead in the form we used to know, people think Spring is pushing a design based on JavaBeans specification. Change the documentation please!

What do you think? Please no bashing!

Other flaws coming in future articles…

3 thoughts on “Spring’s flaws”

  1. I agree with you that this “bean” name is not helping Java in general, and Spring in particular. This is a legacy name for a legacy concept that should now disappear. I have seen to much procedural spaghetti code generated but those concept, and I think now Java is mature enough to start doing Object Oriented Programming.

  2. “Maybe Spring 3 will change this by sort of “deprecating” xml configuration.”

    Please NO! Not everybody likes putting non standard annotations in its sources and / or hate XML. Personally I am perfectly ok with XML and the clean separation between code and configuration that it provides.

Comments are closed.