Over a million developers have joined DZone.

Why are we not using Java EE 5?

DZone's Guide to

Why are we not using Java EE 5?

· Java Zone
Free Resource

Bitbucket is for the code that takes us to Mars, decodes the human genome, or drives your next car. What will your code do? Get started with Bitbucket today, it's free.

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-RPCand JAXRJAX-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 Sundidn'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 ?

Bitbucket is the Git solution for professional teams who code with a purpose, not just as a hobby. Get started today, it's free.


Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}