Since I last revised this article in May, 2005, the Spring Framework has continued to
grow in popularity, and has become the de facto standard for enterprise Java
development. It has progressed from version 1.2 to the present 2.5, and has been adopted
in an even wider range of industries and projects. In this article, I'll try to explain what
Spring sets out to achieve, and how I believe it can help you to develop enterprise Java
applications.

meaning that you can choose to use just about any part of it in isolation, yet its
architecture is internally consistent. So you get maximum value from your
learning curve. You might choose to use Spring only to simplify use of JDBC, for
example, or you might choose to use Spring to manage all your business objects.
And it's easy to introduce Spring incrementally into existing projects.

architectural thinking behind Spring. However, the core architectural concepts go back to
early 2000, and reflect my experience in developing infrastructure for a series of
successful commercial projects.

There are now almost 40 developers, with the leading contributors devoted full-time to Spring development and support at Interface21. The flourishing open source community has helped it evolve into far more than could have been achieved by any individual.

plumbing that would be left up to you if you use only Struts or other frameworks geared to particular J2EE APIs. And Spring's configuration management services can be used in any architectural layer, in whatever runtime environment.

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.

scenarios, the Spring Framework provides mock objects and testing support
classes. Spring also provides unique \u201cintegration testing\u201d functionality in the form
of the Spring TestContext Framework and legacy JUnit 3.8 support classes that
enable you to test your code quickly and easily, even while accessing a staging
database.

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, or want to avoid two phase
commit.

POJOs containing only your business logic, while the framework takes care of the many
value adds you need to build enterprise applications \u2014 even in areas that you may not
have considered when initially authoring the application. This goal requires a
sophisticated framework, which conceals much complexity from the developer. Because
your business logic is abstracted from infrastructure concerns, it\u2019s also likely to enjoy a
longer life, improving the return on investment of writing it. Business logic should
change at the pace of your business; only if it is abstracted from infrastructure concerns
can the impact on your code base of inevitable infrastructure change (such as choice of
application server) be minimized.

Spring's main aim is to make enterprise Java 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. We believe that Spring provides the ultimate
programming model for modern enterprise Java.

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 or web container. For the same reason,
we don't provide an O/R mapping layer. There are good solutions to this problem such as
TopLink, Hibernate, JPA and JDO.

Spring does aim to make existing technologies easier to use and does aim to provide a unified, simple yet powerful programming model. For example, although we are not in the business of low-level transaction coordination, we provide an abstraction layer over JTA or any other transaction strategy that is more portable, easier to use and makes code easier to test.