Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
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) –  Mahmoud Hossam 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
    
add comment

7 Answers

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.

share|improve this answer
add comment

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

share|improve this answer
    
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
add comment

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.

share|improve this answer
3  
+1 for noun soup, although I don't tend to have this problem myself –  Gary Rowe Feb 3 '11 at 7:56
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
2  
a bit more background on why "you'd have to be crazy" please. Its pretty much the de facto standard java app framework. –  NimChimpsky May 9 '12 at 15:17
1  
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. –  Paul Sanwald May 9 '12 at 17:22
add comment

The "tying" in itself is a disadvantage, always, with any framework.

But you can use a lot of Spring's functionality without tying your business logic to Spring. Although there are features in Spring that would tie you to it, the documentation discourages you from doing that.

I use Spring in a lot of projects, but I'm not "tied" to it in any of them.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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