What’s New in Spring 3.0? - Spring Enterprise Recipes: A Problem Solution Approach - page 67

C H A P T E R 2
■ ■ ■
What's New in Spring 3.0?
Spring 3.0 is upon us. It marks an evolution of a framework that revitalized the state of enterprise Java
forever. Since its debut, Spring has had decidedly ambitious goals, not the least of which was to simplify
enterprise Java development. It attempted this before Ruby on Rails, Django, and Scala came out of the
woodwork. The framework has in many ways shaped the evolution of Java and contributed to a change
of mindset in the Java community at large.
When the first version debuted, it featured simple, common-sense libraries that tied together
otherwise boilerplate idioms and reduced them to their simplest elements, as reusable libraries. It
built these abstractions on top of a solid, Plain Old Java Object (POJO)-oriented dependency injection
container. Spring 1.0 expressed the configuration format in a simple XML schema that mapped, one
to one, to objects and properties. With Spring 1.0, you could create objects that would be wired in a
hierarchy that looks exactly as it would if you showed the objects in Java. It was possible to get a little
bit of indirection through the use of a BeanFactory , but otherwise the result was plain and easily
understood. The BeanFactory hid the construction of the object that was created. One small BeanFactory
could create a very complex object graph if it needed to.
This approach made the functionality in the libraries even more charming because there was very
little to imagine. What you saw was what you got. The POJO-oriented approach meant that applications
could be unit tested because it was easy to use interfaces. This was a feat worthy of praise because it flew
in the face of the Java EE “best practices” being shopped at that point. It proffered that applications were
essentially different variations of the same kind of stuff: plain objects in a container. It didn't presume to
be better than everything else, but instead it took a conciliatory approach, integrating with anything and
everything being used in any quantity by anybody: Struts, Hibernate, JDO, Java EE, JSP, servlets, Java
Database Connectivity (JDBC), Enterprise JavaBeans (EJB), Java Message Service (JMS), and much more.
As the framework grew, it did more and more to relieve the complexity from building solutions in
Java EE and popularized many patterns that would eventually be codified in the standards, including
dependency injection. With the hard things made simple, the framework took the next step and worked
to make possible the impossible. Solutions that were otherwise estranged or enjoyed only a niche place
in the market suddenly surfaced in an easy-to-use manner. One example is AOP, which was considered
largely a relic of academia.
Spring 2.0 brought XML schemas, which meant even more indirection. It became a little harder to
understand what was going on in certain places, but it also brought an extra level of abstraction to the
framework. This was an overall gain. It meant that many different idioms could be packaged and reused
in a schema, sparing the user the tedium of reimplementation each time. It did for some of Spring's
more hairy idioms what Spring had done for raw Java EE code years earlier. Spring 2.0 also saw dramatic
changes in the Spring landscape. A much improved AOP solution was introduced, built on AspectJ. It
introduced numerous new libraries for things that simply hadn't been introduced before. Dynamic
languages (Groovy, Bean Shell, JRuby) gained broad support in the container, too.