“A little Madness in the Spring Is wholesome even for the King” Emily Dickinson (1830 - 1886) (via quotationspage).
Bob Lee (a.k.a. crazybob) just lit off at one of the Java proleteriat’s holy cows: Spring.
“no offense to Rod et al … [but] I haven’t been able to get my head around your framework.”
His complaints?
- Most of its proponents don’t know enough about it to justify its use
- Spring isn’t required for dependency injection - it’s just one implementation
- It isn’t lightweight or simple - and it only seems that way when compared to J2EE
- Why XML? (And particularly a dialect that looks suspiciously like Java)
- Loss of type safety
- API dependency
- Too much inheritance
- Not enough generics
- No scoping
The post seems to limp a bit towards its conclusion, due perhaps to its length, and instead of discussing alternatives he calls for pragmatism:
“… simply adopting dependency injection design patterns gets you 90% of the way”, and “Be skeptical, critical.”
All in all, his criticism is well put, and some of it justified - Ted Neward certainly thought so, as did Hani Suleiman, who weighed in early on the (long and interesting) comment trail.
I used Spring (I admit it) at my former employer and some of the issues mentioned resonate with me. A lot of libraries are required, and mixing and matching jar dependencies for the 5 or 6 open source components in your enterprise application is no fun at all. Do I use commons collections 2 or 3? Can I just put the latest build of commons logging in there to get rid of the classloader bug? Maybe, who knows? You just have to suck it and see, then pick up the pieces later.Update: Wrong, see below.
As for XML configuration, well that soon gets long and frightening. Sure, you can break it up (sort of) but it is still a pain to create and maintain - particularly as there’s no decent editor (correct me if I’m wrong). Eclipse will tell me if the class I reference doesn’t exist in a Java file, but no such joy in the Spring XML. You have to (again) suck it and see. Update: Wrong again, see below.
Dynamic languages and comprehensive test suites may be the ant’s pants, but sometimes I just want a compiler error. Now. Not some obscure error in 5 … or 15 minutes once my test run has completed.
On the positive side, I liked that I didn’t have to roll my own. I liked the way it worked with Hibernate. I liked the way I could change its behaviour by writing a configuring class. I liked the way I could extend it to other areas of our application. Yes, I could have written it, but sometimes there are deadlines, and there’s only so much framework fun you can fit in.
So crazybob, criticism is healthy, and pragmatism is an underrated virtue but … what’s your alternative? I’d like to see a follow-up post that expands further on what you see as a better solution - how, for example, do you use the dependency injection pattern in applications you write? Would you expand more on your generics idea? What are the best-practices you think we would be best to practise?
Update: a very well-written comment by Keith Donald responds to this point by pointing out both that very few dependencies are required and that there is a good editor (Eclipse and IDEA). Thus I got those points badly wrong, and on points that could have all-too-easily been checked. An important lesson - thanks Keith.