A Spring summary: The Spring framework is still relevant
By Ken Rimple
With the advent of the simpler versions of Java EE comes a chorus of Java EE aficionados calling for developers to jettison proprietary application frameworks and embrace the core. Spring is one framework targeted for elimination, and several articles and tutorials have claimed that it's obsolete.
To kick off a regular monthly column on TSS, I'll tackle the question of why the Spring framework is still popular today. I'll discuss the platform's strengths, innovations, the power of the Spring container, contrasts and comparisons with Java EE, and some areas where SpringSource, a division of VMware, is totally ahead of the game.
Before I begin, let me lay my bias on the table. I've been working with Spring since 2006, when I ran into it on a project at my prior employer. I had been working with Java EE since the original 1.0 version and Java since 1.0.2. When I saw how the Spring framework simplified my life, I looked for a chance to work with it more. Having a background as a mentor, trainer and leader, I approached Chariot Solutions about teaching Spring in 2007, and I've been here ever since.
Chariot is a SpringSource/VMware training and solutions partner. I lead our training team, but these opinions are my own. Chariot also partners with a number of other technology firms in the enterprise application integration and development space.
Why is Spring so popular?
Simply put, Spring is so popular today because it simplifies development drastically for Java EE developers. Rod Johnson created Spring when he was writing a book on J2EE application design and felt the frustrations that most of us had with the specification. One chief concern was the emphasis on architecting separate Enterprise JavaBeans and processing them to generate deployment JARs. Another was the API's focus on framework interfaces -- home, local and remote interfaces -- not to mention that back in 2001, it took an expensive, heavyweight platform such as WebSphere or WebLogic to deploy these applications.
Dependency injection won the day
The Spring framework simplified everything that Java enterprise developers do today. Every component in Spring is a simple Java object. Developers deploy business beans alongside other Java classes in the same Web application without worrying about generating deployment JARs for business components.
Everything in Spring is based on business interfaces. The code asks for an instance of an implementer of an interface, and then calls methods just as it would call another class. The inversion of control container wires everything together based on some simple instructions. This makes it easy to access collaborators. It also allows developers to run integration tests on components by booting a Spring container or test components in isolation using unit tests, stubs and mocks.
Everything we're talking about here has been provided by the Spring framework for close to a decade. And it doesn't require any special application server to run; Spring's container can run inside of any Java runtime.
The JBoss team wrote the Seam framework to provide a context dependency injection (CDI) container for Java EE. Parts of Seam made it into Java EE 6 as the CDI specification, which provides the same features Spring developers have been using for years. In fact, CDI (JSR-299) is supported as a dependency injection model in Spring, even outside of a Java EE container.
About the Author
Disclosure: Chariot Solutions is a SpringSource Value Added Training Partner, a Sonatype Maven training partner and partners with other vendors such as Engine Yard and TypeSafe. The opinions in this article do not represent the opinions of Chariot Solutions.
Ken Rimple's Spring summary
This is part one of a five-part series. Check out the other parts below.
Part one: Why Spring is still relevant
Part two: Compare and contrast Java EE and Spring
Part three: JDBC chases Spring
Part four: The case for Spring
Part five: Refuting the case against Spring
11 Jan 2013