BT

Tackling Misconceptions About Spring

| by Scott Delap Follow 0 Followers on Aug 08, 2006. Estimated reading time: 2 minutes |
Spring has transitioned from a bleeding edge project to widely used component of enterprise applications written in Java today.  As with any popular project misconceptions start to arise.  Steve Anglin recently blogged on oreillynet.com about 10 common misconceptions developers have about Spring, summarized here:

    1. Spring is not lightweight. It aims to do everything and is becoming fat and bloated.
    ... the Spring Framework has been designed from day one to be non-invasive and modular. You can and should choose only what is needed for your particular project, but as requirements evolve, you can incrementally add (or remove) modules. The Spring team emphasizes keeping things as simple as possible ...

    2. Spring is overkill for simple applications.
    As mentioned in the previous point, the Spring Framework can help you to keep things as simple as possible. You can use only what you need initially yet adapt and extend your application as requirements become more clear....

    3. Spring does not scale to handle very large applications
    Spring is used for very large applications by hundreds of the biggest corporations in the world. The Spring Framework is well-established in the enterprise development space where it is meeting the demands of applications for banking, government, and the airline industry ...

    4. Spring forces you to use Aspect-Oriented Programming (AOP) which is experimental.
    Some of Spring’s powerful capabilities leverage a technique called Aspect-Oriented Programming or AOP (see chapters 3 and 4), but as always you can choose whether or not to use those particular features ...

    5. Spring replaces Java Enterprise Edition (JEE).
    This is one of the most common misconceptions about Spring and yet one of the most misguided. In fact, Spring is largely about Java Enterprise Edition (JEE) integration. Spring offers a compelling alternative to the traditional, heavyweight Enterprise JavaBean-based component model while still leveraging the full power of the other JEE standards ...

    6. Spring and EJB are mutually exclusive.
    In the previous point, we described Spring as “a compelling alternative to” EJB. However, Spring promotes choice - including the choice of using EJB. 7. Spring cannot take advantage of Java 5 annotations like EJB3 does.
    Pitchfork , an add-on for the Spring Framework, supports JSR-250 and a subset of the JSR-220 (EJB3) annotations. Pitchfork is a result of collaboration between Interface21 and BEA and is published under the Apache 2.0 license ...

    8. For a large application, Spring’s XML can become a maintenance nightmare.
    If not managed properly, Spring XML files can indeed become too hard to edit and too easy to break. Here we point out how using the right tools and the right techniques can address some of the specific issues you may encounter ...

    9. Spring does everything with reflection, so it is slow.
    Spring does not do everything with reflection, but it does make extensive use of reflection. Therefore, we want to clarify the role of reflection in Spring and discuss the performance characteristics of reflection in general ...

    10. Spring MVC is complex and not as simple as the rest of Spring.
    Spring MVC is highly-configurable and highly-extensible due to its interface-based design. It uses well-established design patterns such as the strategy (e.g. ViewResolver) and the template method (e.g. SimpleFormController) ...

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Missed the point by j c

Its not that Spring doesnt strive to be simple. Or that it doesnt strive to support every ahem aspect of POJO programming.

Its whether that direction is even valid because POJO programming is a sad answer to the weak direction Java has taken for along time.

I would be suspect of Spring just because it tries to solve all the problems that have been assumed to be the real problems in Java for so long.

Which other languages (please count the times the author spammed us with the word Enterprise) either solve more simply or dont see as problems in the first place (yet still have solutions to).

So Spring away but its a Java specific solution addressing the problems the Java community itself (including SUN) has created for itself and pretended to solve.

Re: Missed the point by Corneil du Plessis

Inversion of Control or Dependency Injection are well documented patterns that are not specific to Java.
Spring uses it as a starting point to solve a whole host of common tasks in a consistent and well defined manner.
The end result is that the core POJO model becomes the focus of developer activity.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss
BT