Spring is the most popular application development framework for enterprise Java™. Millions of developers use Spring to create high performing, easily testable, reusable code without any lock-in.

Firstly, let’s be clear on Spring’s scope. Although Spring covers a lot of ground, we have a clear vision as to what it should and shouldn’t address. Spring’s main aim is to make J2EE easier to use and promote good programming practice. It does this by enabling a POJO-based programming model that is applicable in a wide range of environments. Spring does not reinvent the wheel. Thus you’ll find no logging packages in Spring, no connection pools, no distributed transaction coordinator.

All these things are provided by open source projects (such as Commons Logging, which we use for all our log output, or Commons DBCP), or by your application server.  For the same reason, we don’t provide an O/R mapping layer. There are good solutions to this problem such as TopLink, Hibernate and JDO.

Spring does aim to make existing technologies easier to use. For example, although we are not in the business of low-level transaction coordination, we do provide an abstraction layer over JTA or any other transaction strategy.

Spring doesn’t directly compete with other open source projects unless we feel we can provide something new. For example, like many developers, we have never been happy with Struts, and felt that there was room for improvement in MVC web frameworks.

With Spring MVC adoption growing rapidly, it seems that many agree with us. In some areas, such as its lightweight IoC container and AOP framework, Spring does have direct competition, but Spring was a pioneer in those areas. Spring benefits from internal consistency. All the developers are singing from the same hymn sheet, the fundamental ideas remaining faithful to those of Expert One-on-One J2EE Design and Development. And we’ve been able to use some central concepts, such as Inversion of Control, across multiple areas.

Spring is portable between application servers. Of course ensuring portability is always a challenge, but we avoid anything platform-specific or non-standard in the developer’s view, and support users on WebLogic, Tomcat, Resin, JBoss, Jetty, Geronimo, WebSphere and other application servers. Spring’s non-invasive, POJO, approach enables us to take advantage of environment-specific features without sacrificing portability. Look at some of the benefits Spring can bring to a project:

• Spring can effectively organize your middle tier objects, whether or not you choose to use EJB.
• Spring takes care of plumbing that would be left up to you if you use only Struts or other frameworks geared to particular J2EE APIs. And while it is perhaps most valuable in the middle tier,
•   Spring’s configuration management services can be used in any architectural layer, in whatever runtime environment.
•  Spring can eliminate the proliferation of Singletons seen on many projects. In my experience, this is a major problem, reducing testability and object orientation.
•  Spring can eliminate the need to use a variety of custom properties file formats, by handling configuration in a consistent way throughout applications and projects.

Ever wondered what magic property keys or system properties a particular class looks for, and had to read the Javadoc or even source code? With Spring you simply look at the class’s JavaBean properties or constructor arguments. The use of Inversion of Control and Dependency Injection (discussed below) helps achieve this simplification.

• Spring can facilitate good programming practice by reducing the cost of programming to interfaces, rather than classes, almost to zero.
•  Spring is designed so that applications built with it depend on as few of its APIs as possible. Most business objects in Spring applications have no dependency on Spring.
•  Applications built using Spring are very easy to unit test.
•  Spring can make the use of EJB an implementation choice, rather than the determinant of application architecture. You can choose to implement business interfaces as POJOs or local EJBs without affecting calling code.
•  Spring helps you solve many problems without using EJB. Spring can provide an alternative to EJB that’s appropriate for many applications. For example, Spring can use AOP to deliver declarative transaction management  without using an EJB container; even without a JTA implementation, if you only need to work with a single database.
•  Spring provides a consistent framework for data access, whether using JDBC or an O/R mapping product such as TopLink, Hibernate or a JDO implementation.
•  Spring provides a consistent, simple programming model in many areas, making it an ideal architectural “glue.” You can see this consistency in the Spring approach to JDBC, JMS, JavaMail, JNDI and many other important APIs.
•  Spring is essentially a technology dedicated to enabling you to build applications using POJOs. This desirable goal requires a sophisticated framework, which conceals much complexity from the developer.
• Thus Spring really can enable you to implement the simplest possible solution to your problems. And that’s worth a lot.