Are there any disadvantages in tying my application to Spring framework?

I'm not talking about bugs or issues like that, if any. I'm talking about strategic, architectural things that will influence my application lifecycle.

Should I prefer Spring over Java EE core features supported by EE container? What are the advantages?

  • well,that might not be a direct disadvantage to spring itself,but the learning curve for Java EE is pretty steep (A.K.A. very time consuming) Feb 2 '11 at 19:52
  • What did you intend to use it for?
    – user1249
    Feb 2 '11 at 23:04
  • Its easy to end up with messy code like this programmers.stackexchange.com/questions/114181/…
    – Richard
    Oct 13 '11 at 19:46
  • I'd just note that history so far has shown a long lifetime for standard Java SE and EE technologies. Boring and tedious, yes, but still supported. This may or may not be important to you. It is to us, and Java EE 6 is actually quite nice.
    – user1249
    May 23 '12 at 9:11
  • 1
    linking to this question on SO, thinking it might be relevant here. Jul 14 '15 at 13:30

Since other posts here mention the upside, I'll mention the negative aspects of Spring. Even with these negatives, Spring is omnipresent in its niche, reliable, and works as advertised.

So, on to the negatives:

  • Enormous: I wouldn't like to put jars with 3000 classes into my little hobby project.

  • There are some descriptions of it as slower than some other DI frameworks like Guice or Pico. anecdotal, and probably not too important.

  • Dealing with some parts of spring can be frustrating when they're not well documented parts of the core and documentation you do find diverges across the multiple major versions.

As a side effect of its size, be prepared to spend joyous hours digging through piles of classes that while logically named, start to merge together into a gigantic pile of nouns when you're tired ("sure, you just connect your TransactionAwareConnectionFactoryProxy to your UserCredentialsConnectionFactoryAdapter to your .. zzzzzzzz "). To be fair, they really are logically named, it's a reasonable response to the size of the framework, but still.

Possibly as a result of this adaption of new pieces, spring can be slow, at least for me. Not so much with core spring, but there are connectors for just about everything, and they're not all as well documented as they could be, and that's when you start wading through noun soup. Again, it's really all just in response to its size.

  • 14
    +1 for noun soup, although I don't tend to have this problem myself
    – Gary Rowe
    Feb 3 '11 at 7:56

There are very few downsides to Spring

I thought long and hard in order to find any serious downsides to using Spring, and I'm afraid I've failed. Spring is an excellent toolkit within the JEE/OSGi models. It provides a wide range of non-invasive templates that greatly simplify working with the often cumbersome supporting APIs provided by application containers.

Spring vs the core JEE

Spring does not replace the core JEE technologies - well maybe EJBs but with the new EJB3 specification there's hardly anything in it - instead it provides templates to make using them much easier. Consider JAX-RS the RESTful web services API. Spring provides the RestTemplate which is typically used as follows (assume it's injected):

SomeJaxbAnnotatedClass object = restTemplate.getForObject(someURI,SomeJaxbAnnotatedClass.class);

This will go off to someURI get the XML/JSON/YAML and unmarshal it into the domain object you specify. All in a single line of code.

Exceptions and error logging are handled as runtime exceptions making it easier to keep the local code clean. Spring even works to reduce external dependencies wherever possible so the above example only uses the java.net.* packages).

There are templates for JMS, JAX-WS, JPA, JTA and on and on. All of them make it much easier to work with these standards and make your code cleaner and less error prone.

Pick'n'mix architecture

From an architectural standpoint, Spring emphasises a lightweight pick'n'mix approach. This has the effect of allowing system architects to avoid the use of bloated all-for-everyone application containers such as WebSphere, JBoss or Glassfish and choose their lightweight counterparts instead - Jetty, Tomcat and so on.

Why is this important? The larger application containers have a much longer update cycle which suits the needs of some clients more than others. Banks do not need to be as agile as a one man startup.

If you want to make use of the latest verson of supporting frameworks then you are unlikely to find them in the large application containers. Instead, you'll need to include them manually and Spring makes this easy.

Also, you only need to include specifically the technologies you need. The application containers will give you JMS, EJB and every other acronym under the sun, but you just want easy persistence with JPA. Include Spring and Hibernate and you're done.

So why not Spring?

Avoid Spring if you want to go with the vendor-specific implementations of libraries. Also, avoid it if you want to keep your configuration details within your classes rather than externalising them into XML or JNDI. And definitely avoid it if you think free and open-source solutions are not suitable for your environment.

  • 2
    #1 Spring is not free software. Only open source. #2 Spring applications take multiple time to deploy than JEE applications. Re-deploy times may be even higher. See: blogs.oracle.com/arungupta/entry/why_java_ee_6_is #3Tomcat is in no way lightweight. It is a huge, insecure memory-leak machine. Deploy on Tomcat always takes singnificantly more runtime memory and applications perform far worse than on JBoss or Glassfish you mentioned. New full-blown JEE servers like WildFly have much lower memory requirements and are far better in every way. Jul 23 '15 at 13:32
  • 4
    I'd suggest you look into Spring Boot - it's extremely fast and lightweight. JEE containers are on the way out and are being replaced with microservices.
    – Gary Rowe
    Jul 23 '15 at 13:58

one interesting thing that Martin Thompson mentions in this article is that spring can have a non-trivial impact on GC times:

Keep call stacks reasonably small. Still more work to do here. If you are crazy enough to use Spring, then check out your call stacks to see what I mean! The garbage collector has to walk them finding reachable objects. -Martin Thompson

This kind of thing won't be a big issue for most sorts of apps, but it's a very real concern for the kinds of apps Martin is referring to.

  • 2
    a bit more background on why "you'd have to be crazy" please. Its pretty much the de facto standard java app framework. May 9 '12 at 15:17
  • 2
    it's a quote from Martin Thompson. I haven't done the same analysis he has, but given his research I'd give some weight to his opinion. May 9 '12 at 17:22

Spring really is good. Spring Core is fine. I would add to the other points, if you are in the niche category where performance is truly a concern, you'll want to avoid the other Spring modules, only if you are in the hands of top developers. This is only a concern if you are running a system where performance really is critical. In the hands of average to good developers, Spring will probably actually give you a performance boost by helping to write clean simple code.

  • Compared to raw servlets, Spring can NEVER give you a performance boost. Spring runs on top of servlets.
    – stepanian
    Aug 2 '14 at 5:50
  • @stepanian, you're talking about Spring MVC, I suppose. Spring core isn't related at all with servlets.. Jun 23 '16 at 21:03

Spring has basically become part of the platform now. Everywhere in JEE5 and 6 you find more and more resource injection, so at least that part of Spring, if you stick with it, is/will be just another part of the platform, (see @Inject ). Other parts...not so sure of, especially when it comes to aspect oriented programming. There are other providers of those services, Guice, originally from Google, and Weld, from JBoss, I believe built on Guice, will supply the same functionality if you stick to the JSR-330 Java dependency injection specs.


  • The JSR-330 spec is very limited - it requires consiuos effort to stay within it and not end up in a container dependency.
    – user1249
    Feb 2 '11 at 23:04

Spring does try hard to be non-invasive in terms of keeping it loosely coupled from your application code.

It's also moving more in that direction over tiem. In earlier versions you'd need to extend base classes, then it moved to annotations, and nowadays it's more and more use of POJOs configured in XML.

This is a huge strategic benefit over other application frameworks.

Not the answer you're looking for? Browse other questions tagged or ask your own question.