Thursday, September 24, 2009

On the lightness of Spring

Shortly after I blogged about the direction of Spring, I came across a blog entry asking "Is Spring still lightweight?" The resulting DZone discussion is spirited, but last I checked it nobody actually defined what it means to be lightweight. That seems unfortunate. If the Spring folks are no longer right in their claim to be lightweight, we should at least have a falsifiable proposition. Way back in 2004, Rod Johnson in his book "J2EE Development without EJB" defined the characteristics of a lightweight container (summary of chapter 6):
  • Non-invasiveness: imposing minimal special requirements on application objects run within it
  • Quick start up
  • Lack of any special deployment steps
  • Light footprint, enabling it to run in any architectural tier
  • Ability to manage objects of any granularity, including fine-grained objects that cannot be modelled as EJBs.
Now when we look at SpringSource's mission statement today concerning the Spring framework, we see pretty much the same ideas. They no longer talk about a light footprint, though the spring.jar super-bundle in the 2.5.6 release is still under 3 MB. While you can get the footprint much smaller by using the individual Spring modules (spring-core.jar, spring-context.jar etc), I don't think the footprint is an issue.

What Spring really stands for is the non-invasiveness: the framework helped make POJO development trendy. We have Spring to thank for the new status quo in enterprise Java, where we don't have to inherit from mandatory classes, write unnecessary boilerplate or otherwise deal with much accidental complexity. Spring's idea of lightweight containers --along with Hibernate -- gave us dependency injection, AOP, declarative transactions and POJO object persistence. When we think of Spring as being lightweight, we really mean its adherence to the principles I quoted above.

There are some aspects of Spring that I find unnecessarily tedious, verbose and complex. Sometimes, I am tempted to apply the word "heavyweight" to Spring. And it is true that SpringSource has become a big company with a confusing proliferation of commercial products. But I would not deny the title of "lightweight" to the core Spring framework according to principles defined by Spring, nor would I begrudge a measure of gratitude to a programming paradigm that transformed an industry.


  1. What specific aspects do you find tedious, verbose, and complex? Going into specific detail about them could help the community make Spring better!

  2. Thanks for writing this. I've grown very weary of hearing people say "Spring isn't lightweight anymore" by applying their own definition of lightweight that Rod never intended.

    If anything, Spring has become even lighter over the years with regard to invasiveness. Take Spring MVC for instance: At one time we had to extend Spring-specific classes to create controllers. Now Spring only invades my controllers with annotations. While some may debate that annotated POJOs aren't really POJOs, you must agree that annotations are significantly less invasive than forcing us to extend controller base classes.

  3. spring made me learn some best practices, which i apply to projects where i do not use spring (like programming to interfaces) etc..

    complexity depends on how much u use. or u think u must master to feel reasonably comfortable.. it industry is becoming more heavy weight by that yardstick..

    spring is also heavy weight in that sense.. but then again it depends on what u think u need for the job. u cannot learn and know everything..

    for ex. i use hibernate support in sporing.. never used spring jdbc.. but i need not know until i that does not make spring all depends on what u think is important to learn.

  4. Chris

    I came up with a set of criteria in a blog entry last year: see

    On the basis of this, I'd regard core of Spring as lightweight, although some of the technologies being promoted by SpringSource somewhat less so.