Why are we not using Java EE 5?
By Antonio Goncalves

Editor's note: I saw Antonio's posting and thought that he was echoing many of the things that we have heard at Javalobby over the past 2 years. His perspective is well-informed too, he's the author of a book on Java EE 5, available from Amazon.fr. He was also too modest to mention that he is the leader of the Paris JUG. - Matt

Believe it or not, in a few months the Java EE 5 specification will be two years old (Final Release on the 11 May, 2006). And nobody is using it.

We have all read about how easier the development model is in Java EE 5 compared to J2EE 1.4. Complexity reduced, less XML file descriptors, less code, injection and so on. Despite all these good things, Java EE 5 projects are not taking off. Here are some reasons why :

Java EE 5 is a rupture more than a continuity. J2EE 1.4 and Java EE 5 are really different. That means development teams have to be trained to something new and develop new projects leaving behind years of EJB CMP or JAX-RPC. Some teams have invested a lot in J2EE 1.4 and are willing to wait a little bit more and see. And what if Java EE 6 is another big rupture again ?

Java EE 5 is based on Java SE 5 (heavy use of annotations). But JDK 1.4 is still widely use in projects, making it impossible to migrate to Java EE 5

Even if Java EE 5 is much simpler than its predecessors, it is still too complicated and has many specifications. With profiling in Java EE 6 the number of specs will be reduced, but until now, to be Java EE 5 compliant, application servers have to implement 23 specifications.

Today the application server race is completely different from few years ago. Websphere is the number one for big projects and, as usual, is late and is still not Java EE 5 compatible. On the other hand, just when companies had started to use open source with JBoss, JBoss has left the race and version 5 is still in beta. Weblogic, the very innovative company (you should look at Weblogic Virtual Edition) has been bought by Oracle. God knows what will happen. GlassFish is by far the best open source Java EE 5 app server. But people still don't know it well. And if some do, they immediately remember the previous reference implementations made by Sun (the ones used to play with the Java Petstore) that were not usable for real life project. GlassFish is.

Many simpler frameworks arrived before Java EE 5 and took over. Of course there is Struts. JSF came after with a different development model but it is so different from Struts that projects don't want to invest on it. Axis and XFire brought a nice way to develop web services while J2EE was still struggling with JAX-RPC and JAXR. JAX-WS with JAXB 2 are great but arrived too late. Hibernate while we were mesmerised by EJB 2.1 CMP complexity. And of course, Spring which has become a serious Java EE competitor. It is lightweight, lets you do plenty of what Java EE does, so why make the move?

To make it more blurred in developers' minds, most of these open source framework are now implementing some Java EE 5 specifications. For example, Hibernate implements JPA now (even if it does more). And because Hibernate was here before JPA, a developer using annotation and an EntityManager will still say that he/she develops with Hibernate, not JPA. Same thing for Axis implementing JAX-WS now. How frustrating is that ?

Some words have become evil. “EJB“ for example. No matter how much easier EJB 3 is, it‘s still called an “EJB“ and that reminds us of bad memories because we remember Home/Remote interfaces, Bean classes with empty methods, XML files and JNDI lookups with narrowing, difficulties with testing… Another word issue is the “Entity Bean“ one. We all remember the Entity Bean 2.1 nightmare (heavyweight and over complicated). Unfortunately, JPA kept the name “Entity“ when talking about a persistent object. The word “Entity“ is too close to “Entity Beans” and that scares developers.

Talking about how words can have an impact on you, the naming used by Sun didn't help either. Nobody knows what they are talking about and they get confused with J2EE 1.4, Java EE 5, JDK 1.5, Java 5, Java SE 5. So when you arrive at a job interview and say “I‘m a Java EE 5 expert”, one will turn to you saying that you are not up to date because they use Java 6 and not Java 5.

The definition of Java EE has been completely twisted. Tomcat is seen as Java EE. Look at the job ads and you will see : "looking for a Java EE expert who knows Tomcat, Spring, Hibernate"... hum, no Java EE in there. Again, EE 6 profiling will make these things clearer, but until then, Tomcat is not a Java EE 5 app server.

Testing a Java EE 5 application is definitely not as easy as a Spring application. We live in a world where everybody talks about test, but nobody really does it. Java EE 5 doesn‘t help in this aspect.

Conclusion : some aspects of Java EE 5 are still not at their best (testing, injection could be better, JPA still has to get richer, JSF model is a bit complex..), but the overall is that Java EE 5 is definitely much easier than its predecessor, J2EE 1.4. Projects that are using Spring might not see the benefit of Java EE 5. Except that these big projects are all using Spring within an app server (for clustering and performance issues). Upgrade your app server and start developing some EJB 3.0. You‘ll see how easy it is (and you can even combine Spring and EJB). For projects in J2EE 1.4, well, if you use Websphere, you are stuck, for the others, upgrade your app server (Weblogic 10, GlassFish 2…) and develop your new projects with Java EE 5. It is backward compatible and you can call an EJB 3 from an EJB 2.1. Do not migrate yet, just let both versions co-exist.

And you, why don't you use Java EE 5 yet ?

Until next time,
Antonio Gconcalves
http://jroller.com/agoncal/