History

Spring has established itself as a very popular solution for Enterprise Java applications. In particular the advantages of Spring as compared EJB 1.x / 2.x were very obvious and were a major reason for Spring's success.

The Current State

Due to Spring’s early success and adoption, Java EE 5 and Java EE 6 were pushed to greatly simplify the Java EE programming model, increase developer productivity and become much simpler to use than previous versions. The current Java EE 6 solutions are thus just now achieving the ability to compete against Spring's programming model. Developers now are ready to ask the question "Why you would prefer Spring?" Here is my take:

• Many key elements of Java EE 6 such as JSR-330 (@Inject), Common Annotations (@Resource, @RolesAllowed etc) and even some EJB annotations (@TransactionAttribute, @Asynchronous etc) are supported by Spring. So you can choose a programming model that is very similar to the Java EE programming model.
• There are differences, among others: Spring typically uses Singleton beans, EJB typically used pooled beans - and of course the annotations for them are different. But do you really think this will impact productivity or even the success of a project?
• However, Spring is much more flexible. Instead of the annotations mentioned above you can choose XML or Java based configurations. You can create custom extension using AOP. You can use the JMS and JDBC abstractions - all of that is not included in Java EE. So the programming model Spring can almost be considered a superset of Java EE. Usually more power and flexibility to choose different options is considered a superior solution.
• There is a difference in platforms that you can deploy on: Typically you will need to use Java EE application server for Java EE solutions while Spring is perfectly happy to run on Tomcat or other simple servers. Tomcat is the predominant server in the marketplace so this is actually an important difference. (Let me add that you might use OpenEJB on Tomcat i.e. you can support more of the Java EE APIs on Tomcat if you really want to.) Also there are problems: If you want to run Java EE 6 you are limited to the very small set of certified servers. If you have a strategic commitment to an application server vendor who doesn't support Java EE 6 you can still use Spring. If operations won't install the latest release of your application server, you can still use Spring. Spring happily runs in these environments.
• Of course Java EE also has an advantage: the fact that Java EE is baked into the server. Therefore you don't need to deploy it with the application which can make some things easier. It might be easier to set up your infrastructure. It might be easier to package and share your application. But I personally would prefer to be flexible in deployment over these advantages.

Before we start a flame war and get lost in technical details let me reiterate: Java EE and Spring can have a similar programming model. Spring is more flexible and I would prefer it. But: I don't think your project will fail because of the decision you made concerning this. And: I think a Java EE vs. Spring shoot out will be boring. If you do a side by side comparison you will end up with minor differences such as @Component instead of @Stateless or whether you will need to deploy some additional JARs. While that might be impressive in a demo I don't believe this will convince anyone to use one platform or the other. Certain features of Spring (e.g. the flexibility to use XML or Java based configuration) will probably not be shown as they just cannot be done using Java EE.

Why I don't care

So if a side by side comparison doesn't make a lot of sense - why would I choose Spring? There has to be a clear advantage somewhere to definitely answer this question. A personal note at this point: I am frequently work at a shared office space with some JavaScript and Ruby on Rails guys - I am the only Java guy there (and sometimes I think they pity me). After talking a lot with these other developers, I believe we need a compelling Java story that can live up to their developer experience. If Java EE and Spring are both on a comparable level concerning productivity we need to come up with novel ideas to improve. Looking at Ruby on Rails helps here - the approach is to combine a dynamic language with a powerful framework and a code generator. The next level of productivity is not Java EE vs. Spring. It must be something that can counter the productivity of Ruby on Rails. I believe this is:

• Groovy / Grails: it combines a dynamic language with a powerful framework and a code generator - like Ruby on Rails. The only difference is that the solution is more adapted to the JVM and has better integration with Java, the most important platform in the Enterprise space.
• Spring Roo: it combines Java/AsepctJ with a powerful framework (Spring) and a code generator - like Ruby on Rails. This is easier to learn for Spring developers than Groovy / Grails and has therefore appeals to a different audience.

So if you look at productivity the comparision should not be "Java EE vs. Spring" but rather "Groovy / Grails vs. Spring Roo vs. Ruby on Rails". Better productivity is not gained on the level of the framework or the programming model any more.

Asking the Wrong Question

The other reason why I think "Spring vs. Java EE" is the wrong question is: Both models on their own do not solve the challenges I typically see in projects. Let me give you some examples:

• Integration: Today almost any project will need to integrate with other technologies through file transfer, Web Services, messaging etc. There are well known patterns for this - the Enterprise Integration Patterns by Gregor Hohpe. Neither Java EE nor the core Spring Framework help here - you will need to use a framework like Spring Integration, Apache Camel or its competitors.
• Batches: A lot of project use batches. They might import data - or to run complex business logic. In the latter case, chances are that the batches are actually mission critical. Neither Java EE nor the core Spring Framework help here - you will need to use a framework like Spring Batch. (I believe there are no real competitors but I might be wrong).
• Caching: Like many of our competitors we at SpringSource believe that caching is a very important part for a performant enterprise solution - you can tell by the product strategy in the Java EE space. Again this is something that Java EE does not cover. However, for Spring a cache abstraction is planned in Spring 3.1. A standard in Java EE - if there is ever to be one - won't be there until the next Java EE release.
• Again looking at my Ruby on Rails office mates: They deploy a lot of projects into the cloud. Offerings like Heroku make that extremly simple. Of course you could run Spring or Java EE on an IaaS like Amazon EC2 or VMware vCloud Director cloud. But it might be easier to use a PaaS that will deal with scaling, fault tolerance etc automatically and it usually offers some interesting additional services. Google App Engine as the predominant public PaaS as well as VMforce have strategic commitments to Spring. The Cloud has clear economic benefits so this technology will become more and more important. The Java platform has to have a solution here - otherwise it will eventually become irrelevant.
• More and more data is stored in non relational databases (NoSQL). Actually that is the only way we will be able to cope with the exponentially growing amount of data and the structures like graphs in social networks or unstructured user content. Again it this quite common in the Ruby on Rails camp - while for Java there is currently a lack of APIs. Java EE has no support - and it won't for a while. There are so many non relational stores a standard will be hard to define in a standards body.
• Also integration in social networks like Twitter, Facebook and other common internet services will be more and more important. Again this is common in the Ruby on Rails community. And at least one of my customers with a very large web site mentioned this as "a feature marketing will love" - remember Facebook is almost as important a source for internet traffic as Google nowadays. We need solutions for this in the Java space.
• Messaging: In the Java EE community the JMS standard has been very stable for 10+ years. Outside the Java community there was actually innovation. Therefore a lot of the office mates use RabbitMQ - and that is also the predominant messaging solution on the EC2 cloud. It is standardized on the protocol level (AMQP) and it is much more flexible (not just topics and queues). That is why SpringSource bought Rabbit Technologies and why we are investing considerable resources in the Spring-AMQP project.

So there are a lot of challenges Java EE just has no solution for. A side by side comparison of Spring and Java EE might lure you to believe that JSF + Spring / Java EE + database is all you will ever need. Look at your projects and decide for yourself if that is true. It certainly contradicts my experience.

Sum Up

To cut a long story short:

• You won't see a lot of change in your productivity if you use Spring or the newest Java EE releases. The next level of productivity is not about these programming models but about Groovy / Grails or Spring Roo.
• Spring and Java EE will only be a part of your technology stack. You will need to look at solutions for a lot of issues outside these. That is why SpringSource and others are currently investing heavily in creating such solutions for the Java crowd. And a lot of these solutions are well integrated with Spring.

...and a last thing

So you have read this blog post to the end. That is great - thanks a lot! Please don't start a religious battle now. Instead code something or do something fun. Enjoy!

Labels: I don't care, Java EE, Spring

¶ 10:42 37 comments