The relationship between Spring and Java EE has aspects of real human drama. There is the powerful giant that refused innovation for years (J2EE). There is the contrarian crusader that wanted to set things right (Spring). Development shops abandoned J2EE ship in droves and took shelter with Spring. Then the giant woke up and changed its ways (Java EE6). And with that response, the world became much less black and white. What is the role of Spring now? How will it react to the new ground realities?
Answering these questions is not easy. Any kind of blanket statement about Spring or Java EE will be a folly. They are both collections of different frameworks and technologies. A far better conversation will involve analyzing these frameworks and technologies separately. This will give one a better picture about where Java EE 6 has done well and where Spring is still beating it.
Before I delve into the technical details, I must address the issue of human emotion, especially in relation to trust. It is a fact that people have been burnt by Java’s lack of innovation in the server space for far too long. Spring became a savior for them. People will not forget that so easily. Java EE 6 implementations (JBoss, WebSphere etc.) are more than a year old now. Spring continues to be very much in the hearts and minds of the developers. I make that statement based on two observations:
- Have a look at the job postings in Monster or Dice. A very large proportion of Java jobs require Spring experience.
- There has been a lot of innovation lately in the cloud space. None of the major Platform as a Service (PaaS) providers, like Amazon Beanstalk and Google App Engine, support Java EE 6. They all support Spring effortlessly. The fact that Spring works in the highly restrictive Google App Engine environment is nothing less than stunning.
The continued dominance of Spring, as I conclude by the end of this article, is largely due to emotional inertia and some technical advantages.
Let’s now have a look at the technical aspects of Spring and Java EE 6. I will limit this article to the areas where I can claim some expertise and experience. Even in those areas, I can not claim absolute knowledge. These are then, my personal opinions. They are open to correction based on your feedback and my own learning.
Dependency Injection (DI)
Context and Dependency Injection (CDI) feature of Java EE 6 has been very well put together. It is easy to learn and use. I think, for most common tasks, CDI is just as good a DI tool as Spring.
A down side of CDI is that it needs a full Java EE container. Technically, CDI will not work in plain Tomcat. Although, others have found simple workarounds to getting Weld working in Tomcat. Last time I checked, Weld is still not supported by Google App Engine.
Web Model View Controller (MVC) Framework
JavaServer Faces (JSF) is the official out-of-the box MVC framework in Java EE. JSF 2.0 has been a major improvement. Unfortunately, JSF is still a big mess. It is a fine framework for building a 90’s web site. But, a pain in the neck for building a modern HTML5 web site with complex Ajax interactions and SEO friendly URL. I will almost always suggest Spring MVC framework over JSF for most projects.
Time has come to completely rethink Java’s MVC strategy. My own Pink framework leverages all that is great about Java EE 6, like CDI and Bean Validation (JSR 303). It practically matches Spring MVC feature by feature. We need something similar out of the box from Java EE.
SOAP and RESTful Web Service
Java has done a tremendous job with JAX-WS and JAX-RS. I have used both extensively. Just like CDI, they are very well put together, easy to learn and use. At the same time, they support proper programming practices like contract first design.
I had a brief look at Spring-WS. I really fail to see why Spring even bothered to create this module. For all practical purposes, I will recommend using JAX-RS and JAX-WS.
The preferred component model for Java EE is EJB. In the past, EJB had been cumbersome and pain to work with. A lot has changed since then. In Java EE 6, you can:
- Create EJBs right inside a web module. There is no need for a separate EJB module.
- Define local EJBs without any business interface.
- Lifecycle methods are completely optional.
In other words, EJBs are now just as easy to develop as Spring components. Spring documentation continues to say things like “The negatives of EJB in general are so great that this is not an attractive proposition”. Really? I can’t really agree to that. Neither can I agree that Spring’s transaction management is any better or worse than EJBs.
This is an area where Spring enjoys an undisputed advantage. Spring, in all it’s glory, will work in plain Tomcat, Google App Engine and Amazon Beanstalk. This includes, DI, JPA, transaction (local only) and the whole deal. Tomcat, GAE and the likes do not care much for Java EE certification. They live happily in a symbiotic relationship with Spring.
Unlike Spring, different Java EE specifications are implemented separately. For example, CDI comes from Weld, Bean Validation comes from Apache BVal, JPA from Open JPA and so on. Getting these to work together is a Herculean task. In fact, that is what the fine folks at TomEE are trying to do. It has taken a number of developers almost a year to put all the pieces together on top of Tomcat to create a full Java EE 6 web profile.
Summary and Conclusions
Spring has made tremendous contributions to the development community. One indirect contribution is the competition that it gave to Java EE. Java finally woke up and responded with Java EE 6. Unfortunately, one of the most critical pieces of Java EE – the MVC framework – remains deeply flawed. In all honesty, I will always steer my clients to frameworks like Spring MVC, Struts 2 and Stripes. The second advantage of Spring is its support for almost any web container, including the awkward ones like GAE. These two advantages will continue to cause Spring’s dominance in development projects.
Out of the two main disadvantages of Java EE 6, JSF 2.0 is more critical. Java badly needs a modern MVC framework. Startup companies avoid Java like plague. Enterprises prefer Spring MVC (based on what I have seen in the job listing sites). If this gap is somehow filled, either from Java EE (which is highly unlikely at this time) or from third party (like my own Pink framework or something like Struts 2), then Java EE will pose a formidable challenge to Spring.