Ken Rimple's case for Spring includes comparisons to Java EE, but he also expounds on improvements Spring and other languages have brought to the JVM.

Looking at Spring vs. Java, I see a strong case for Spring over Java EE. If Java EE is considered to be "the way" to develop all things on the Java platform, it has failed. Developers still use Hibernate annotations in a Hibernate-backed JPA container because the feature they want isn't available to them in the Java persistence API (JPA). Not everyone is focused on writing JavaServer Faces (JSF) applications, either. New technologies, such as single-page Javascript Web applications, will develop much more quickly than the Java EE (or even Spring) APIs will.

TheServerSide has been updating its resources in terms of the Spring framework, Java EE contexts and various different approaches to inversion of control (IoC) and dependency injection (DI). Check out these newer resources on the topic:

The answer for whether to use a particular API or platform must be based on the merits and the situations the developers are faced with. To be fair, in Part One of Spring to Java EE Migration, the author makes this same comment. I am aware of the bias involved in my selections and try very hard to debate the merits of all options.

We must not forget this when designing greenfield applications or upgrading existing ones. Certainly greenfield applications have their choice of options, Java or no, and often these choices are dictated by the makeup of the development team, existing applications and where the company sits between conservative, stay-the-course technology selections and remaining on the cutting edge.

Would it be wise to gut a legacy Spring model-view-controller user interface built with Spring Beans in order to move to Java EE's JSF and EJB on the existing application? How unstable would that make the new design until the migration effects settle down? Developers make choices to stay with an existing platform in some cases because the expense and stability risks to the applications don't make up for the risk of the change. On the other hand, when an existing platform becomes too bloated to work with, then more drastic action may be required, and we've done that as well.

It's about innovation and choice

Open source development is about choice. It is about the meritocracy of innovation, not about following one corporation's "way." If someone comes along with a better, sleeker, easier platform for Java EE to test, configure and deploy than Spring, I would like to see it. And I might use it.

But as I look at Spring vs. Java, these three facts remain: Spring is indispensable because it provides code that can be run on any Java platform, it separates business logic from enterprise platform abstractions and doesn't impose a terrific amount of complexity on developers.

The Spring community is not tethered to a multi-vendor community process, so it can move quickly and try new things. Sometimes these attempts fail: Witness the attempt to build an OSGi-based application server. The SpringSource dm Server was highly innovative, but, internally, it was a commercial failure. Rod Johnson spoke about this publicly, admitting that they were either early or had bet on a horse that just wasn't ready for the market. However, that didn't stop SpringSource from trying. In fact, the company donated the dm Server codebase to the Eclipse foundation, where it became the Eclipse Virgo project, which is still being developed today.

Another SpringSource product, which is gaining in popularity, is tc Server. This server was developed at roughly the same time as the dm. It has since become a key part of VMware Inc.'s vFabric product line.

Non-Java EE innovations

SpringSource also built APIs that go further and abstract more complex processes. Their Spring Integration API has building blocks that build enterprise service bus or integration projects. The components are based on Gregor Hohpe's Enterprise Integration Patterns, and can be configured in Java, Scala or XML.

Another integration tool built by SpringSource is Spring Batch, which attempts to handle chunked data-loading processes. Batch can handle data from a variety of sources and write that data using a number of APIs.

SpringSource also purchased a non-JMS queuing tool based on the AMQP API, RabbitMQ and a NoSQL database, Redis. SpringSource developers are building a set of data management abstractions, the Spring Data APIs, to handle a variety of NoSQL and SQL database APIs, even implementing the NoSQL REST Data project to handle a RESTful website as if it is a database.

None of these APIs sit behind a pay wall. None of them require developers to purchase support. Development teams are free to download them, set them up and run them on company servers without penalty. If management wants support, they can pay for it. If they would rather support the applications internally, the team still has full access to the source code.

Ken Rimple's Spring summary

This is part four of a five-part series. Check out the other parts below.

Start the conversation

0 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.