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.
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.