Re: Spring was Re: resource injection in java EE webservice
On 09/27/2010 06:36 PM, Arved Sandstrom wrote:
Tom Anderson wrote:
On Mon, 27 Sep 2010, Lew wrote:
gk wrote:
Yes. I am comfortable with "dependency injection" . I have gone
through that section in Spring Framework . setter Injection and
Constructor Injection .
I have come to detest Spring.
Could you, briefly at least, explain why?
I don't know what Lew will say, but this link
(http://www.web4j.com/Criticisms_Drawbacks_Pitfalls_Spring_Rails_PHP.jsp#Spring)
sure covers all the problems I had with it, not to mention a few more that
hadn't really begun to irk me before I abandoned Spring. Granted that link
is a few years old but I doubt they've fixed all the problems - there's too
many of them.
Pretty much the main negative impression that I had of Spring, when
seriously trying to make a go of it maybe half a dozen times over the past
few years (and mostly with Spring 2.5), was that the team couldn't have made
the framework more complicated and rambling if they'd tried. The
over-reliance on XML configuration, as also explained in the link, is a big
mistake IMO. Also as mentioned in the link, Spring is bloatware: back when
Spring Security was still Acegi I experimented with that too, and ended up
needing to pull in ridiculous amounts of JARs...not to mention that the
configuration for that was clumsy too.
My belief is that the bad habits of Spring were engrained starting with its
release in 2002, and it just exploded into more badness. Java EE 5 and 6,
IMO, have eliminated any possible residual attraction that Spring may have
had.
Do you have an opinion on Guice?
What do you think of autowiring?
Interesting link: http://java.dzone.com/articles/why-you-should-use-springs
I agree with the guys that don't like it. And yeah, I tried it too. :-)
I'm still trying to work out how i feel about dependency injection
frameworks. There's at least one good idea in there, but there seems
to be a lot of cruft and madness surrounding it.
tom
I know what I think the good idea is: for example, being able to get at a
session bean by using @EJB and declaring an instance variable to the
interface, rather than doing a JNDI lookup and a
PortableRemoteObject.narrow(). And so on and so forth. It's saving me some
boilerplate.
Because that's pretty much all *I* want - maybe a few dozen "macros" - I
have very little patience for something like Spring that makes it so bloody
complicated.
What Arved and Arne said. Confronted with Spring projects, I feel like the
kid who got very excited by a room full of horse manure, exclaiming, "With all
that shit, there has just /got/ to be a pony in there somewhere!"
My assessment is based on coming in to existing Spring-based frameworks. The
latest uses old versions, including the Acegi framework. It's XML hell, but
not the worst I've seen. The worst used Spring to configure every GUI
component. You couldn't trace even the simple screen structures for love or
money. You have Java code that hides a component behind a String that looks
up a component from an XML description that requires another String to look up
a nested component that uses a String to find ...
Too much salt destroys a meal. Too much dependency injection destroys type
safety, code dependency linkages, readability, maintainability, reason,
sanity, and your love life.
I suspect I'd have had a better opinion if the real-world usages hadn't been
so egregiously mis-engineered. But so far every Spring-based app I've seen
has had these flaws. It's as if the official tenet of the framework were,
"Screw you, maintenance programmers!"
Well, screw Spring! It's ghastly. What's so danged awful about just
instantiating and using a class instance anyway?
--
Lew