Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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.
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.
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.
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.
YMMV
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.
