Wille Faler’s Buzzword Bingo

For the record: I kind of like Spring, I’ve used its IoC-container for the better part of the last 3-4 years and I’ve been the driving force behind Spring adoption on several previous contracts.
However, as far as the core bits of the Spring Framework go, a lot of it grew more out of trying to paper over the cracks of the original, fundamentally flawed J2EE architecture and programming model than anything else.
About 90% of J2EE was so crappy up until “JEE 5″, that Spring (with Hibernate) was a natural “replacement” for a lot of it, and pretty good at it as well. However, that doesn’t mean Spring is perfect, maintaining a big application and its configurations is not a walk in the park. In fact, I’d say Spring is starting to show its relative “age” in some areas, it is the first commercially successful framework of its kind (much like Struts 1 was the first successful Java web framework). In practice that means that some of the design decisions of Spring where good, but not perfect, and other frameworks have popped up, learning from Spring by making better design decisions where Spring’s where flawed, and retaining the good ones.

The fact that Spring was borne more out of J2EE flaws than anything else has become very apparent to me in recent months, while getting to know new frameworks such as Wicket and JPA. Using the Wicket/JPA combination as an example, compared to the “last-gen” frameworks of the same kind, like WebWork and (older versions of) Hibernate there is a vast difference:
With WebWork and Hibernate, however good they actually where (and lightweight compared to a full J2EE stack), I always found myself wanting to shove Spring further and further into their territory.
With Wicket and JPA I found myself in the opposite position at first, I was scratching my head thinking: “huh, now where would I want to use Spring?”.

The answer to my last question was: Not in very many places at all.
In fact, I’d say there is probably a case for not using Spring at all in a Wicket/JPA application, if there are no links to other types of systems or frameworks and database interactions are all there is to it. You just don’t need it, the code and the application will be just as clean and nice anyway done right.

I think this conclusion also gives at least some weight to the point some people argue, that “Design Patterns to some degree exist to solve flaws in programming languages and frameworks”: Springs popularity and use grew out of fundamental flaws in Java in general, and J2EE in particular. As those flaws have been rectified by new JEE specifications, and better frameworks (such as Wicket), the need for Spring is suddenly diminishing (which is probably why the Spring people are so eager to add everything, including a kitchen sink into the Spring distribution to hedge their bets for the future).