« previous 1 2 3 4 5 6 7 next »

Clearing up

In some areas, however, old approaches will be replaced by new ones. For example Spring 2.5 introduced controllers in its Web MVC framework and support for JUnit 4 - both based on Annotations. In these areas, the old approaches are considerably less elegant and will, therefore, be "deprecated" in Spring 3. They include parts of the web controller hierarchy (for example SimpleFormController) in Spring MVC and the (AbstractDependencyInjectionSpringContextTests classes of JUnit 3). Developers should no longer use these, now deprecated classes, in new projects. The reference documentation no longer discusses them, to avoid misleading new users. The Javadoc documentation is not affected.

Apart from marking some elements as deprecated, the Spring developers have also completely removed some features from the framework. One of these features is the support for Commons Attributes. This technology was used to achieve similar options with JDK 1.4 as the ones offered by Java 5 annotations. Since the new framework is based on Java 5, this feature has become obsolete. Also no longer supported is the proprietary TopLink API – Oracle now propagates the Java Persistence API (JPA)instead. Struts 1.x support will also be discontinued. As this feature is still bound to be used by many people, SpringBeanAutowiringSupport offers a new alternative. – Incidentally, the Struts 2 development line itself is based on Spring, so there was no need for Spring to integrate it.

By clearing up, the Spring developers want to ensure that the framework will continue to be true to its motto of being "simple yet powerful". Without such measures, new users would find it increasingly difficult to familiarise themselves, just because the framework is weighed down by a host of features that no longer interest anyone. Otherwise, Spring continues to strive for backwards compatibility. 100 per cent of its APIs and 95 per cent of the extension points are reportedly in keeping with those of version 2.5.

Another change affects the project's layout. Spring has always been highly modular. Nevertheless, spring.jar has been available as one file, including all the modules and there was even a distribution that included all the dependent libraries. While some users consider this an advantage, it meant that, by defining an environment with various library versions, Spring had to start managing dependencies. This task is best left to other technologies like Maven, ivy or OSGi.

As a result, Spring 3 only offers individual Spring modules, which can be integrated via OSGi or Maven. The framework also supports these two technologies for the dependent libraries. In addition, SpringSource offers the Enterprise Repository (see glossary), a collection of libraries that have been tested in the OSGi context. This way, users can add libraries to their projects and use the well-established OSGi, ivy or Maven technologies for dependency management.

Next: REST everywhere

« previous 1 2 3 4 5 6 7 next »