Spring: an Alternative to Java EE

When Java was first created by Sun Microsystems in 1995, it was the end-all and be-all of programming languages. Java set the tone for how the development process was going to be shaped for years to come. The client-server relationship was leveraged so that it no longer mattered what platform the user was running; the software would run on a server with the results being delivered.

Over time that philosophy has drifted as stewardship for Java has been transferred to Oracle, whose goals are not as closely aligned with the open-source movement as Java's creator Sun Microsystems was.

The Java EE Problem

The best-known platform for enterprise-level Java applications is Java Enterprise Edition, which is described as a platform rather than a language. By blurring this line, Java EE makes it confusing for companies to understand where the language ends and the platform begins. Applications developed in Java EE must stay in Java EE; they can be migrated from one Java EE server to another, but they need that environment in order to run. This is philosophically in conflict with Java's independent architecture: users aren't required to have a specific operating system to run a Java program, but Java apps created in Java EE are locked into Java EE servers.

What many companies don't understand is that a Java application, once developed in Java EE, must be hosted on a Java EE server, period. This can put artificial constraints on future planning and compatibility. It also means that dissatisfaction with the platform will have to be lived with or addressed with an expensive rewrite of the code.

That dissatisfaction can crop up in a number of ways. Here are two big ones:

Disparate support. Each application server vendor provides its own support in Java EE, so it's up to you and your developers to track down the source of any conflicts and work to resolve them. Support levels and response times can vary, and it's not necessarily easy to predict the best vendors ahead of time.
Slow to change. Java EE doesn't change with the times, at least not as quickly as many developers would like. New releases of the platform come out on average every three years. While they are feature-rich, the long innovation droughts in between force developers to come up with workarounds to adapt new concepts. Your good idea can take a lot longer to implement than you're expecting if it's been awhile since there was a new Java EE release. The fact is that Java EE is not nimble or versatile enough for your company to commit to it from here on in.
 

The Spring solution

There is an alternative to creating Java applications exclusively for the Java EE platform. Spring 3 is a framework that makes it possible to bring together tried-and-true Java programming with whichever state-of-the-art hosting technology makes sense for your organization. It is updated frequently by its open-source community, which is why Spring is more adapted to emerging best practices than Java EE, which sees a new release about every three years.

The first version was written by Rod Johnson, who released the framework with the publication of his book Expert One-on-One Java EE Design and Development in October 2002. The framework was first released under the Apache 2.0 license and has been supported by the open-source community ever since.

Spring applications don't require a Java EE application server to function on. When creating web applications, the developers can easily switch among a variety of open-source servlet containers to ensure that the apps behave as intended. No expensive rewrites are needed to switch from one hosting solution to another.

What's more, Spring 3 as a framework has incorporated aspects that promise to keep it platform agnostic going forward. Spring is:

Modular. The framework is broken into individual modules, and your developer can pick and choose which ones best fit your needs. If a particular module seems too clunky or inflexible, you aren't stuck using it.
Non-invasive. It's possible to assemble a complex system from a set of loosely-coupled framework independent components (POJOs) in a consistent and transparent fashion. In other words, business and data access objects will not be tied to Spring or any framework. This ensures re-usability.
Supported. Commercial support for Spring is easy to find, and the experience is consistently professional. By keeping support under the same roof as Spring's architects, patterns can be quickly detected.
Adaptive. What the market wants, Spring provides, and it does so with near immediacy. If the development community is aware of a trend, such as the Agile movement, then Spring is updated to conform to the new standards.

In short, Spring not only allows you to select the platform that best fits your needs without regret, it also isn't going to make you regret your decision to use it as a framework in the first place. Spring is adaptable, responsive, and brings together the widespread acceptance of Java with the versatility demanded by today's software market.

The modular nature of the Spring framework, together with its frequent release schedule, make it the ideal development environment for Java applications. As mentioned, testing is easier using Spring than via Java EE. In addition, Spring is platform-independent, meaning that the applications don't have to be developed and run on Java Enterprise Edition servers. This widens the field considerably in terms of selecting a developer and deciding how to host the application. Finally, the Spring framework has a centralized support network, rather than expecting you to chase down individual vendors for various APIs to help solve problems as they crop up.

Further reading:

Spring home: http://www.springsource.org/

Spring and Java EE: http://www.fransvanbuul.net/?p=68

Spring and Java EE 6: Synergy or Competition?: http://www.infoq.com/presentations/Spring-Java-EE6

JavaOne debate: Java EE vs. Spring: http://www.infoworld.com/d/developer-world/javaone-debate-java-ee-vs-spring-560