In light of some criticism and even attacks (justified or not) that are out there, here are the ten most common misconceptions about Spring from SpringFramework.org.

The Ten Common Misconceptions About Spring

For those new to the Spring Framework, we feel as though it is necessary to address some of the concerns you may have when approaching Spring for the first time. In fact, we have compiled this list based on our collective experience in training new Spring users and observing discussions and forums throughout the Java development community. It is our goal to shed some light on these issues so that you will be better equipped to make well-informed decisions regarding the adoption of Spring on your next project.

1. Spring is not lightweight. It aims to do everything and is becoming fat and bloated.
Spring’s primary goal is to enable lightweight development based on POJOs. As a developer, you should be able to focus on your domain-specific business logic rather than infrastructural issues and convoluted contracts. You should be able to rely on the framework to solve your integration concerns. However, when building enterprise-class applications, there can be an abundance of such concerns. So in a sense, Spring does aim to do everything that you - as an enterprise developer - might expect an enterprise framework to do. Spring supports such a vast array of enterprise services and third party products that it may in fact seem fat and bloated at first.
However, in order to provide a comprehensive integration platform for enterprise software development while simultaneously supporting full stack POJO-based development, 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. This applies to Spring itself, and most importantly to applications built with Spring.

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. It makes sense that such an environment provides favorable conditions for simple applications.
For one thing, even simple applications typically require some enterprise services such as transactional database access. In that case, the simplest option may be to rely on Spring’s data access integration and declarative transaction management. Furthermore simple prototypes have an uncanny way of transforming into production applications. If you are responsible for such an application, you will appreciate a lightweight yet scalable framework that can handle those demands.

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.
One example is Voca, whose services are used for payment of household bills by over 70% of the UK population and for paying over 90% of UK salaries. They’ve relied on Spring to process over 5 billion transactions in 2005 - with over 72 million on a peak day.
Other acknowledgements of increased productivity and performance for large scale Spring-based applications include an online system for the French Taxation Office built by Accenture and an enterprise application of the European Patent Office. (SpringOne 2006 Keynote, Antwerp, Belgium)

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. Furthermore, Spring 2.0 has significantly improved its AspectJ integration which means there is an increasing range of AOP options to choose from. Many users become comfortable with the core concepts by using Spring’s proxy-based AOP and then begin applying AspectJ when the extra power is necessary.
Before letting FUD guide your decision-making process, there are a few things you should know. First, Spring’s proxy-based approach to AOP relies on the use of standard JDK dynamic proxies. That means that this functionality is actually enabled by the core Java language. Second, AspectJ is the product of many years of research, and is now a well-established de facto standard. Third, AOP is very focused on a particular limitation of Object-Oriented Programming and is therefore best viewed as a complementary rather than revolutionary technique.
Traditional OOP is unable to modularize certain “aspects” and thereby leads to code duplication and scattering of orthogonal logic such as auditing, security, etc. Once you overcome the initial learning curve (which is surprisingly easy once you break through the FUD), AOP is a very natural approach to solving that problem. For example, in a Spring-based application, you can provide transaction management to your entire service layer without modifying any of the code. That means the application is more flexible and easier to maintain while the code is kept clearly focused on business logic. Based on that and similar capabilities, you may join the increasing number of developers who are more than willing to begin experimenting with AOP.

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. One motivation is to simplify the usage of JEE APIs so that developers are not forced to repeatedly write extensive amounts of code. Another motivation is to encourage decoupling of application code from the JEE services. Spring offers a consistent approach to promote productivity, and where applicable, Spring provides abstractions to promote flexibility.
Spring’s integration support for JEE APIs includes:
· Java Message Service (JMS)
· Java Management Extensions (JMX)
· Java Transaction API
· JEE Connector Architecture (JCA)
· Java API for XML-based Remote Procedure Calls (JAX-RPC)
· JavaMail
· Java Naming and Directory Interface (JNDI)
· and Enterprise JavaBeans (EJB) including version 3.
Support is also provided for some very important Java Standard Edition technologies such as Java Databae Connectivity (JDBC) and Remote Method Invocation (RMI) as well as JEE 5 additions such as the Java Persistence API (JPA or the EJB3 persistence specifications). Spring consistently applies this same approach for integration with well-established third party products such as Hibernate, iBATIS, Quartz, Hessian, and so on.
Spring’s JEE integration is never based on the “lowest common denominator” approach. On the contrary, every effort is made to preserve access to the full power of the underlying technologies. In other words, while recognizing that 80% of the time you only need 20% of the functionality - the remaining 80% is available when needed.
For in-depth coverage of this particular topic, see “Expert One-on-One J2EE Development without EJB” by Rod Johnson and Juergen Hoeller.

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. Spring provides support classes for implementing EJBs and providing them with access to the managed beans of a Spring container. Spring also provides a configurable proxy mechanism that allows EJB client code to have dependencies only on simple business interfaces. The details of EJB remote access, JNDI lookups, and the associated exceptions are all hidden behind the proxy and managed by Spring. That abstraction is very useful for integrating EJB-based legacy code with newly developed POJO-based code. Since the client is no longer concerned with those details, this approach also provides a convenient migration path between EJBs and POJOs. Interestingly, if you choose to use EJB3 and the associated POJO-based model for persistence (JPA), you will likely find the migration path from a Spring-based application to be much smoother than from an application based on an earlier EJB version. Furthermore, with Spring you can take full advantage of JPA without using any other features of EJB3 if you so choose.

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. It not only provides the foundation for WebLogic’s EJB3 implementation, but it also enables extension of the EJB3 programming model via the Spring Framework.
Core Spring 2.0 provides full integration support for JPA (EJB3 persistence) including its annotations. Spring 2.0 also adds support for @AspectJ-style annotations. Other annotation support in Spring includes transaction management, JMX configuration, and dependency validation.

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:
too error-prone
Using the proper tools is essential. An XML editor provides code-completion and validation by leveraging a DTD or XML Schema Definition (XSD). One of the major focuses in Spring 2.0 has been on XSD-based configuration which provides considerably more information to the editor. Spring-specific IDE support as provided by IntelliJ or the Spring IDE plugin for Eclipse adds even more, such as providing completion of Class names and suggesting properties available in bean definitions. If you choose the names from a dropdown list, you will save time and you will not produce any typos.
too difficult to navigate
XML files should be split up to reflect the structure of your application’s modules. As with your code, it makes sense to keep related configuration information together and have clear separation of concerns.
too cumbersome for simple properties that may change frequently
Certain key/value pairs should be externalized into property files. This prevents that XML files are modified every time one of these simple properties needs to be modified. Spring provides configuration options that will make those properties available to the bean definitions that require them (see chapter 5).
too repetitive
Bean definition inheritance can reduce duplication any time common properties are being set on a large number of related objects. As an example, a single “dataSource” bean definition may be fulfilling a dependency of many data access beans. In that case, an abstract parent bean definition can capture that shared property in one line.
too generic
A major addition in Spring 2.0 is XSD support and domain-specific namespaces. These enable more concise formats for many commonly configured items. It is also very easy to create custom namespaces to provide domain-specific configuration of your own bean definitions or for integration with other frameworks.

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.
Spring uses reflection for its Dependency Injection, but it is important to understand that this occurs only at configuration time (when beans are wired together). From a performance perspective at runtime, it is no different than if you had explicitly set the dependencies in Java code.
Spring uses reflection via standard JDK dynamic proxy objects in its Aspect-Oriented Programming framework. Typically these proxy objects are configured at the coarse-grained service layer where they provide features such as transaction management, security, or exporting objects via remote access. If the call and execution of methods on a proxy object involves the network and/or database access, then the performance impact incurred by the proxy’s use of reflection will be negligible.
In any case, decisions motivated by performance concerns should always be based upon relevant benchmarks rather than intuition or hearsay. If you are using Java 1.3, then some of the traditional concerns about reflection may be valid. For example, in the 1.4 release of Java the performance of the reflection API was improved by 2,000% .

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). Unfortunately it is easy to mistake configurability and extensibility with complexity. As with all things Spring, you can and should use only what is needed, but you will benefit considerably by taking some time to learn what options are available. You will be pleasantly surprised to discover just how simple and well-defined each Spring MVC component is. Each cohesive unit is focused on one small part of the lifecycle of handling an HTTP request and rendering a view. This promotes decoupling of business logic from presentation logic which in turn leads to applications that are powerful yet flexible. Once you use the Spring MVC framework on a project, you will most likely appreciate its power and ease of use. It is actually quite easy to implement a small, simple project with Spring MVC.

What do you think? For more on the new Spring 2.0, here’s a good resource as well.