Ten Common Misconceptions About Spring...

by Steve Anglin

In light of some criticism and even attacks (justified or not) that are out there, here are the ten most common misconceptions about Spring from SpringFramework.org.

18 Comments

Simon
2006-08-03 20:58:33
I agree with most of what you've said - I find Spring suits my needs pretty well, and some of the new stuff in 2.0 is really useful.


Not so convinced about MVC though. To be sure, there are much more complex frameworks out there, but I don't find Spring MVC scales well in terms of maintainability. It's simple enough to develop a single screen, but once you start to get lots of screens, I find I end up having to develop extra infrastructure and new base classes to avoid duplicating code all across the different screens.


Then again, I'm not sure if other web frameworks handle that much better.

jerry
2006-08-03 21:27:48
I started doing web programming for the first time about 5 years ago, and quickly realized that it can get complex pretty quickly no matter what language or framework you were using. That's what drove me to find a solution like the Spring Framework. I was very happy to find something that can scale up as well as down with relative ease and little complexity. I still use Spring to this day for most of my projects, but if I had to make a complaint, I would say that I could definitely benefit from more automated tools. For instance, it would be nice to create a bean, right-click on it in my IDE and automatically add it to an applicationContext.xml along with good guesses of its dependencies. There are other types of functionalities I can think of that would just ease the development process. I use the SpringIDE in Eclipse, and it helps but it's just not up to the point where it does a LOT for me. I don't mind if a tool makes assumptions especially when I am trying to rapidly develop something. Other than that, I think the Spring Framework is truly a good piece of software, and I would have to agree with all 10 of this guy's points.

2006-08-04 18:15:10
Spring is a solid piece of engineering. Unfortunately some people take it to be a magic bullet. It is excellent at making an application testable, robust and flexible. But like all great technologies it is merely one of several good ways of doing things rather than the one and only.
Hani Suleiman
2006-08-04 23:38:05
Well, I spose it's only valid to address the misconceptions that are likely to result from the alleged misconceptions....


1 - Spring is NOT lightweight, if you mean lightweight in some kind of absolutist sense. It's lightweight compared to a full blown container, but is not lightweight when you factor in the fact that you have to write beans, write lots of xml, and have spring do its 'magic'. This is now akin to server startup time.


2 - Spring IS overkill for a certain class of simple applications. In many cases, there's no need for all the wiring magic to be externalised into a configuration file.


3 - Spring does scale, fair enough. It won't do so magically though, you still need to know how to make it scale, it doesn't solve the scalability issue for you; you still need to be a smart developer to do that.


4 - Are there STILL people out there who care about AOP??


5 - This I can't argue with. Though the Spring layer that goes on top of many of the core EE API's are their own form of vendor lockin.


6 - Spring's JPA support is still not entirely pleasant, though this will likely improve over time. Spring does play nice with EJBs though, granted.


7 - Spring does not take advantage of annotations the way that EJB3 does. Spring's approach to annotations so far still forces you to declare all your beans in the configuration file. Granted, it's a hard problem to solve (jar scanning is a nasty business), but in an EJB3 container, it's easier to plop things in and have them work magically than it is in Spring. Pitchfork is a great step in the right direction though (I say this as a happy user of pitchfork).


8 - Spring's xml is crap. Spring 1.x XML is a compelling enough reason to avoid it altogether. With just a handful of beans it becomes a complete mess unless you have autowiring enabled (which the Spring folks don't recommend you do). 2.0 improves that somewhat, but it's still unpleasant and can grow uncontrollably. The XSD support makes validation better, but it's red herring argument. XSD or DTD make no difference to how readable or verbose xml is.


9 - Spring is slow (compared to, say, wiring by hand). I know better than to blame reflection, but 2-3 seconds startup just to scan a handful of beans with annotations and wire things up is not what I traditionally think of as fast.


I don't know much about Spring MVC so can't comment to that.


All in all, this article would have been a lot more useful if it wasn't so keen on being marketing material!

Steven Devijver
2006-08-05 03:49:43
Hey Hani,


Nice of you to drop by. What we've presented here is our personal top 10 of the misconceptions we regularly come across. As you may have noticed or "marketing material" doesn't say any of the misconceptions are plain wrong. We do believe they are out of balance in the minds of some people.


I believe it's useful for developers to be able to make informed choices which is our motivation for writing this top 10. I do not intend to stop developers from using say Ruby on Rails or Grails. I certainly want to prevent them from not using Spring for the wrong reasons.


1 - Spring is NOT lightweight, if you mean lightweight in some kind of absolutist sense. It's lightweight compared to a full blown container, but is not lightweight when you factor in the fact that you have to write beans, write lots of xml, and have spring do its 'magic'. This is now akin to server startup time.


You'll be happy to learn Spring 2.1 will support configuration in Java classes as an alternative to XML. This will proves to be an extremely powerful and flexible means of configuring applications. Ofcourse you will be able to mix XML and Java configuration as you see fit. I assume you have no issues with the Spring 'magic' per se.


2 - Spring IS overkill for a certain class of simple applications. In many cases, there's no need for all the wiring magic to be externalised into a configuration file.


Granted. If you are referring to Ruby on Rails this is a great environment for simple applications. I've read "Getting Real" book and I subsribe to a lot that's being said.


3 - Spring does scale, fair enough. It won't do so magically though, you still need to know how to make it scale, it doesn't solve the scalability issue for you; you still need to be a smart developer to do that.


Do you know of any platform/tool/approach that don't require smart developers to get scalability? You know very well EJB does not scale like Spring-based applications can. This is the difference: with EJB it's going to be very hard to scale. With Spring you have a very good chance to get real scalability.


5 - This I can't argue with. Though the Spring layer that goes on top of many of the core EE API's are their own form of vendor lockin.


I don't see where this "vendor lockin" comes from. There is no more lockin by using Spring template classes than when using the APIs directly. If you're refering to JmsTemplate or JndiTemplate these are a few utility classes that can be used independently from the rest of Spring. The big difference is that you'll be able to write applications that use JEE services and avoid an entire batch of potential bugs.


6 - Spring's JPA support is still not entirely pleasant, though this will likely improve over time. Spring does play nice with EJBs though, granted.


I agree. The main problem are the JPA specs that don't properly support integration.


7 - Spring does not take advantage of annotations the way that EJB3 does. Spring's approach to annotations so far still forces you to declare all your beans in the configuration file. Granted, it's a hard problem to solve (jar scanning is a nasty business), but in an EJB3 container, it's easier to plop things in and have them work magically than it is in Spring. Pitchfork is a great step in the right direction though (I say this as a happy user of pitchfork).


It's good to hear you're happy with Pitchfork. Spring does not attempt to do JAR scanning but nothing's stopping people from writing their own additions. BEA integrates with the metadata abstraction of Pitchfork to provide easier deployment.


8 - Spring's xml is crap. Spring 1.x XML is a compelling enough reason to avoid it altogether. With just a handful of beans it becomes a complete mess unless you have autowiring enabled (which the Spring folks don't recommend you do). 2.0 improves that somewhat, but it's still unpleasant and can grow uncontrollably. The XSD support makes validation better, but it's red herring argument. XSD or DTD make no difference to how readable or verbose xml is.


I'm sorry to hear you don't think the Spring 2.0 XML Schema are a major improvement. We need more time to work out more schemas in more areas, the same goes for projects that build on top of Spring (e.g. Acegi 1.1). But the custom XML that are already available do make a big difference in XML files. Again, it's up to the user how readable their XML files are. Another big contribution to improved readability of the Spring XML files is the new integration with AspectJ Aspects.


9 - Spring is slow (compared to, say, wiring by hand). I know better than to blame reflection, but 2-3 seconds startup just to scan a handful of beans with annotations and wire things up is not what I traditionally think of as fast.


Are you referring to loading a Hibernate SessionFactory of JPA EntityManagerFactory? The Spring ApplicationContext needs much less than 2-3 seconds to load a handful of beans.


Anyway, thanks for sharing your thoughts and ideas.

Anonymous Coward
2006-08-06 14:12:12
Spring in particular and IOC in general is nothing but one of the GOF's original design patterns misrepresented, and then obfuscated behind XML to boot, just to make a handful of consultants a sh!tload of money
Chris Nappin
2006-08-07 05:56:33
The whole XML configuration files issue can be very easily solved by using XDoclet. I'm suprised it's a solution thats not more widely used. We use it with a relatively large team of developers and it works very well.
Hani Suleiman
2006-08-08 12:14:24
Chris, xdoclet is the worst possible solution. You end up with all the downsides and none of the upsides of annotations vs xml.


1) It's loosely typed and error prone (comments are NOT code)
2) it's tightly coupled to source code


So you lose the flexibility of having an external xml file to drive configuration, and you lose the type safety of annotations.


With JDK5, there's no sane reason to use xdoclet.

Apollo
2006-08-08 12:31:21
I feel spring provides an easier and cleaner way to achieve your objectives and there are always pros and cons with any good framework.
One can easily blame for it being crap without understanding it and fully utilizing it in a proper way and for all those of you who have problem with some guys making shitload of money, channel your energies in creating something even better as it will benifit all of us.
Nathan MA
2006-08-08 17:01:21
1. Spring is lightwight compare with Application Server.


2. EJB is overkill for any SME. ONLY large scale application (2000+ concurrent users) will benefits from it.


3. - Spring is only useful for smart developer. -EJB also requires smart developer to make it scaleable.


4. "Are there STILL people out there who care about AOP??" - Nonsense, obviously there are lots of people care about it. Aopalliance, AspectJ, Spring AOP and Jboss AOP are still very active projects leading by very smart people.


5. Vendor Locking? all template are only helper classes, they are optionals. Hani, I reckon you really need to learn spring again if you think you are already good at it.


6. JPA spec is finalised few months ago and I'm sure spring will support it in future release.


7,8. annotation - loosely typed and error prone
annotation - tightly coupled to source code


annotation is crap too.


9. For server application, startup time is not a problem at all. Indeed, hibernate startup time is much longer than spring, if you use hibernate with EJB, you will have the same problem. For development, I use mock object.

Ken
2006-08-08 18:20:10
I'm so confused....so editing XML is a PITA and error prone, but XDoclet sucks because you have no control over the XML? What in the world should you do if you can't do either? :-)


FWIW, I think Java 5 annotations are replacing XDoclet (at least for Spring usage) and hopefully there will be enough annotations so we no longer need to edit XML to get Spring to work right ;-)

L.Garcia
2006-08-09 16:06:24
Hani give us all a break will you? You're only on here yourself to promote your big flapping mouth. A marketing tool if ever there was one.
Dejan Rudic
2006-08-14 06:48:59
[Reply to this "Subtle EJB propaganda" article, posted on theserverside.com]


I would like to point out some comments on the 10 "misconceptions."


> Spring is not lightweight. It aims to do
> everything and is becoming fat and bloated.


Spring is not lightweight. Not if you tend to use everything, that is. It's modular and scalable and will provide you with lightweight combination that suites your business.


> Spring is overkill for simple applications.


Also a questionable misconception. It is true Spring introduces a layer of complexity, but it also preserves/enforces good OOD, patterns and model, thus contributing more then it takes.


> Spring does not scale to handle very large applications.


Also quite false. My bank runs about 50 branches and with more that 1000 employees. Very large financial application is backed up by the Spring 1.2.5 and its scales quite nicely so far. We use Spring container (IoC, beans) and a bit of AOP, that's all.


Additionally, I've developed an EJB-like annotation model and created wrappers for complete Spring, thus hiding it from "daily developers" in order to prevent xml chaos and factories mentioned above. System is reliable and responsive.


> Spring forces you to use Aspect-Oriented
> Programming (AOP) which is experimental.


Well, I don't know how to comment this objectively. Neither is a complete truth. You are not forced to use AOP by no means, and it is as experimental as Spring itself.


> Spring replaces Java Enterprise Edition (JEE).


This is the only misconception I agree completely. But, it's worth mentioning that its not the only thing Spring replaces...


> Spring and EJB are mutually exclusive.


Wrong.


> Spring cannot take advantage of Java 5
> annotations like EJB3 does.


It's a simple case of metadata style that's considered appropriate by the architects. Both approaches have their good and bad aspects, not worth reasoning about it...


> For a large application, Spring's XML can
> become a maintenance nightmare.


So does any type of configuration of a large system. It's true that EJB3 annotations will prove more maintainable that Spring's XML, thought. But it has its down sides as well, and this is not the place for that story.


What is worth reasoning is the amount of pressure introduced on junior developers by xml configuration and java code metadata configuration...


All in all, "misconception" is insignificant.


> Spring does everything with reflection, so it is slow.


This is the weakest "misconception" of all. I frequently quote Mr. Knuth to my colleagues


"Premature optimization is the root of all evil."


Spring has some complex algorithms for singleton maintenance and retrieval (source is available). By no means Spring is slow due to reflection, I suggest you test your "misconception" with some benchmarking - you will find Spring slow, as I did, on some awkward places, but not in reflection code.


> Spring MVC is complex and not as simple
> as the rest of Spring.


Yes, it is not simple as the rest of the Spring and, yes, it is complex. And yes, you don't have to use it if you don't like it.


My ten "misconceptions" would address some misbehaviors and new functionalities like invalid bean querying, lack of wiring inner classes as inner beans, absence of reference wiring, no reconfiguration infrastructure etc.

Dan
2006-08-23 09:29:58
Some of these misconceptions may raise valid concerns. Especially when Spring is compared with other lightweight frameworks like the J2EE Pattern Oriented Framework:


http://jt.dev.java.net/

Manuel
2006-12-03 22:31:54
"AOP is very focused on a particular limitation of Object-Oriented Programming"
Well, I would say it is a limitation of Java rather than OOP, basically it's poor support for metaprogramming: lack of prototypes/open classes, bad reflection support, no introductions, and so on: AOP can be implemented almost framework-less if the language is richer. Take a look at Smalltalk or Ruby which are OOP and don't need Spring. Great post, though :-)
minute San%20Gimignano
2007-03-26 06:31:05
In light of some criticism and even attacks (justified or not) that are out there, here are the ten most common misconceptions about Spring from SpringFramework.org.
I do not agree. Go to http://www.dreamsjobs.info/irrefrangible_Italy/phenomenon_Toscana/minute_San%20Gimignano_1.html
Jose Cano
2007-12-03 08:26:41
Good job !
adi
2008-03-18 16:39:57
Isn't it funny that spring is the only framework widely used for integrating different frameworks through inversion of dependency? At least I don't know another one, mature enough. There is Guice, a fresh one, without most of the drawbacks mentioned in this article, but nobody uses it yet.