Java EE & CDI vs. Spring

 Version française disponible

Last Wednesday, I have attended to the “Stateful is beautiful” talk at Nantes JUG, introduced by Antoine Sabot-Durand.

Expert in Java EE for several years, Antoine has shared his vision for the Java landscape today, especially for Java EE (Enterprise Edition) and the Spring alternative.

Spring is a light-weight container that provides similar features to those found in a heavier Java EE application server. Spring only uses stateless beans, but Java EE also uses stateful beans.

To introduce those two notions, the classic example is the e-commerce application.

On one hand, the shopping “cart” object will be store in a stateful bean. Why? Because we need to maintain a conversational state between requests, from the time the customer has added a product to its cart to the time he would give its credit card information. On the other hand, the stateless state will be sufficient to look through the products catalog. To view a product, we do not care about the products the user has previously visited. Thus, a product will be stored in a stateless bean.

Antoine has made a review of the received wisdom on Java EE. Most of them belong to its history but still pursue it in the latest versions. At the time of J2EE (Java EE 4 and older – i.e. all Java EE releases until 2003), EJB 1.X – 2.1 included has suffered much Java community criticism. Heavy, complex to implement and tricky when your want to test your code, the Java platform dedicated Enterprise has not convinced…

Because of these lacks in Java EE, some Open Source alternatives have become popular such as Spring and Hibernate.

Now, the platform (renamed as Java EE) has evolved and has been simplified, the new EJB 3.X specification has became lighter and more competitive. This is especially true for the latest Java EE 6 release in late 2009. Indeed, it includes CDI (Contexts and Dependency Injection), the standard that it needed to compete Spring seriously. It also includes the “profile” feature that allows Java EE to be specialized. Broadly, you take only the components you need. For testing into the container, Antoine advised us to use Arquillian software.

Spring has chosen not to implement the new CDI standard. Why? The answer is not so simple. Perhaps this implementation would have been impactful on the existing code and could slow down the development of the framework. At the same time, with a large number of users, maybe SpringSource has decided to continue its parallel development of Spring in the hope one day it will dethrone CDI definitely. In general, companies are not keen on changing their habits, knowledge and other best practices (replace Spring by CDI would be a very important investment). At the same time, this can be dangerous if CDI takes off in the coming years. Watch this space!

Note: Unlike Spring, Hibernate implements JPA for the persistence layer (which is the standard in Java EE) ensuring greater longevity.

As Antoine pointed out, the purpose of his presentation was not to denigrate Spring. On the contrary, he continues to use it and could hardly do without it. He has made a metaphor with a “golden hammer” I found rather interesting. Today, majority of Java developers do not ask themselves the good questions when they want to use dependency injection. At the end, they choose Spring spontaneously (we have a nail, oh I just need my Spring favorite hammer). However, we should be able to put the golden hammer down for a while and see what is existing around. Depending on the project, Spring is not always the most appropriate.

Today, the success of Java EE is still uncertain. Received wisdom won’t die, Spring still has a bright future. How much longer? Only time will tell… In the meantime, Antoine strongly advices us to try Java EE 6 and get our own opinion. At the end, he made a demo : a Java EE example project, created from a Maven archetype template and using stateful and stateless beans.