Antonio Goncalves is a senior software architect living in Paris. Initially focused on Java development since the late 1990s, his career has taken him to different countries and companies where he works now as a Java EE consultant in software architecture. As a former BEA consultant he has a great expertise in application servers such as Weblogic, JBoss and, of course, GlassFish. He is particularly fond of Open Source and is a member of the OOSGTP (Open Source Get Together Paris). He is also the co-creator of the Paris Java User Group and talks on Les Cast Codeurs podcast. Antonio wrote a first book in French on Java EE 5 back in 2007. Since then he has join the JCP and is an Expert Member of various JSRs (Java EE 6, JPA 2.0 and EJB 3.1). He then published a second book for Apress: Beginning Java EE 6 Platform with GlassFish 3. For the last years Antonio has been talking at international conferences mainly about Java EE, including JavaOne, The Server Side Symposium, Devoxx, Jazoon… He has also written numerous technical papers and articles for IT Web sites (DevX, JaxEnter) or IT magazines (Programmez, Linux Magazine). Antonio is a DZone MVB and is not an employee of DZone and has posted 32 posts at DZone. You can read more from them at their website. View Full User Profile

Why are we not using Java EE 5?

  • submit to reddit

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 ?

Published at DZone with permission of Antonio Goncalves, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Meera Subbarao replied on Tue, 2008/01/29 - 5:40pm

Hi Antonio,

Nice post.

I am working on EJB 3.0 project and facing a whole lot of problems with different application servers. I have managed to get things working though with GlassFish as well as Oracle Application Server.

What a pity, JBoss doesn't even work with Java 6. Beta 3 does start, but web services don't work.

I have documented all my findings in my blog here.

But, Java EE5 is truly amazing, simple and elegant when compared to the earlier ones.

Meera Subbarao

John Gilbert replied on Tue, 2008/01/29 - 5:43pm

I wasn't sure where this was going at first, but I am very happy with the conclusion! I can also say that I have been using JEE5 for 2 years, along with most of the other tools mentioned, and all is working well! If you are sceptical about the learning curve, then this tool could help: Sorry for the plug, but we really have been able to get new JEE5 developers up and running and productive in very little time! And they have all been glad that they made the switch.


Fred Grott replied on Tue, 2008/01/29 - 6:17pm

 Correction...websphere is based upon compliant javaee5 Apache Geronimo..


Fred Grott(aka shareme) sometimes a JavaZone(JavaLobby) and EclipseZone contributor. Top visited blog on at:

Stuart Doherty replied on Tue, 2008/01/29 - 6:28pm in response to: John Gilbert

This article has come just in the nick of time for me. At first my only real introduction to the world of Java was through a data structures and algorithms course in university. I've been developing in C/C++ for the past 5 years, but in the last year I've been looking to learn a web application framework of some kind to start playing around with some web development. I figured since I was comfortable with Java this would be a good route to go (although I must admit LAMP was an appealing option too). So I dove into reading about Java EE... WELL... now I feel like I'm stuck in some infinite recursion loop where JUST when I think I have things straight I'd read about some other framework/system that starts with J that I was unclear about the role it played in the whole EE stack. Up until just now I thought Spring/Hibernate/etc. were all players under the broader umbrella of Java EE 5... now I'm gathering that they can play together, but are really closer to the Java EE 1.4 world?.... I'm sure I'm already sounding confused. So, here's my bottom line, how the heck do I get all this straight. Its sounding like maybe I can just bail on trying to work with Spring/Hibernate/Struts/J<whatever>, and focus on Java EE 5 and what falls within that world? Would this make sense? I'm thinking this taylor project would be a good start.


I just don't know. It sounds like I should not bother trying to get spring/struts/appfuse/hibernate/etc. straight in my head since Java EE 5 covers the things they do already, and is a more current technology.

Now I'm repeating myself. Can anyone poitn me to an article/book that's written for someone who HASN'T actually experienced the evolution of Java for the web and needs it all spelled otu for them?



Denis Robert replied on Tue, 2008/01/29 - 6:43pm in response to: Fred Grott

Sorry, but that's simply not true. Websphere *Community Edition* is geronimo plus a few cosmetic changes, but Websphere Application Server has nothing to do with geronimo. There are quite a few rumours out there that WebSphere 7, if it ever comes out, might be based on Geronimo, but considering the work IBM put into building 6.1 on top of OSGi, I'm now skeptical of even that.

I used to believe that IBM had big plans for Geronimo. I now think that they were just trying to kill JBoss. They really shouldn't have: JBoss is facing far more considerable foes: Glassfish on the JEE side, and Spring on the "everything else" side...


Siarhei Dudzin replied on Tue, 2008/01/29 - 7:16pm

I tend to agree with the article on some points.

First, there is a 'reputation' of J2EE 1.4 - people switched to lightweight frameworks.

Then JEE 5 came out and looks like many people simple didn't bother due the big delta between 1.4 and 5. While there seem to be huge difference actually there is not, except that you shouldn't compare with J2EE 1.4 but with those lightweight frameworks (Spring+Hibernate+Axis, etc).

It's not the frameworks that implemented the JEE 5 spec, it's the spec that got 'adapted' to the frameworks.

Don't forget, there is direct influence of Struts and Hibernate creators on the JEE 5 spec and Spring influenced it as well. So, big difference? No, just need to re-think what you compare to :)

Siarhei Dudzin replied on Tue, 2008/01/29 - 7:22pm in response to: Denis Robert


I used to believe that IBM had big plans for Geronimo. I now think that they were just trying to kill JBoss. They really shouldn't have: JBoss is facing far more considerable foes: Glassfish on the JEE side, and Spring on the "everything else" side...[/quote]


Well, I think many people still don't trust the reference implementaions so I am not sure if it's really a menace from Glassfish here, at least not until there will be some high volume public sites that are based on one (otherwise it will be just a reference implementation and a 'free' server implementation for communities). It requires quite heavy PR to be seriosly considered by enterprises.

Spring on the other hand doesn't even has its own runtime (at least not yet) I don't see how a framework can be a menace to JBoss? :)

Ronald Miura replied on Tue, 2008/01/29 - 9:33pm


1. You usually use Hibernate, not JPA, unless your application is really simple. This is because the JPA spec doesn't include many optimizations (cache, for example), which were left for implementor-specific extensions. Also, in many cases you use implementation-specific syntax in EJBQL (or just plain old HQL) without even noticing.

2. Java EE is not EJB! Tomcat is not full Java EE compliant, but it does implement a subset Java EE, and an application that runs on Tomcat IS a Java EE application. I mean, an application doesn't need to use EJB to be considered Java EE, am I right? (I know that Java EE is more than EJB + what Tomcat provides, but most developers don't, or don't really care)


Spring doesn't prohibit you from use EJB, but since the former provides almost all services of the latter, in a much cleaner and simple way, it basically makes EJB unnecessary. Many see JBoss as a Tomcat with EJB support, so, if you don't use EJBs, Tomcat is just fine, and you don't need JBoss. So, Spring IS a threat to JBoss, at least in the low-end and 'free-as-free-beer' market.

Farzad Kohantorabi replied on Tue, 2008/01/29 - 9:51pm

Nice comparison. There reason I am still stuck with an older version of Java EE is that we have a product which has been developed with older versions of Java EE and they can still sell it. Unfortunately, the product has used Entity Beans to its extereme, but my understanding of North American business model is that we don't need to change it if we can still sell it. At the same time we have customers which are with an older version of WebSphere (5.1) and we can't just force them to buy an upgrade. Believe it or not, my IDE can do crazy debugging things but it keeps disconnecting from application servers because of annoying jvm bugs in version 1.4. The other thing that is bothering me is that I can't even use ehcache, and similar frameworks, without doing crazy modification because RMI implementation has a bug in version 1.4 and this list continues.  I do face a lot of resitance from management when I plan to move to a newer version.


As for Spring vs Java EE, I do not agree Spring is a replacement in many cases since spring has been designed to be lightweight, even though it does a lot of heavy weight lifting these days, and there are still services spring does not offer. I do like a mix of EJBs and Spring. Spring is very useful for a business logic sort of container.



Rainer Eschen replied on Wed, 2008/01/30 - 7:51am

I've to smile a bit reading such an article these days. Sorry, I'm working with Spring for some time, had a short look at EJB3, and have problems to follow such a perception. It looks like you try to conserve what the market already defines as legacy: 

I understand that you still try to follow the official standards. I did this in the past, too. But, some thoughts about standards from a former Sun Java Architect: 

BTW: The platform for Spring will be Tomcat ;-):

Which projects really need an EJB container these days, besides those that have to integrate EJB 2.1 legacy applications or use the connector architecture anyway?

I had a deeper look at JSF OpenSource implementations and can't share the enthusiasm for this official standard: 

Sure, JSF is comparable to what I did during my desktop development projects in comparison to Struts. But it's overstated complexity delivers error-prone frameworks. The maintenance of code we develop in this context will be more expensive than with Struts legacy of these days. Have a look at what code quality you get in the browser page sources if you don't believe this. Combinations with AJAX are even worser.

Maybe it's a better idea to keep Struts and change to "Flex on Spring" in the next years: 

Tony Colston replied on Wed, 2008/01/30 - 8:19am

There is no question in my mind... Java EE is a bloated piece of shit. Anyone who tells you otherwise has not had the pleasure of working with other toolkits. It started out long ago as a large turd and through each revision the turd has been shined... but it is still a turd.

 You and I could start writing a web app at the same time... and you would be on 3rd or 4th xml description file when I was finished already.

 The reason why other toolkits have taken off and left the turd behind are usefulness. It is plain and simple.

Steven Nakhla replied on Wed, 2008/01/30 - 9:56am

I must admit, I was travelling down the Spring/Hibernate path.  Spring is a great framework that makes it easy to get rolling with large-scale enterprise applications.  After working with it for a while, I wanted no part of Java EE.  However, I recently started playing with the Seam framework from JBoss, and love it.  To me, it feels like Spring for Java EE.  The use of annotations eliminates most of the need for XML descriptor files.  Plus, it integrates well with Spring, Hibernate, and tons of other libraries.  In developing JSF-based applications, I've found it to be far more functional and provide a much quicker development cycle than the Spring/Hibernate combination alone.

Antonio Goncalves replied on Wed, 2008/01/30 - 4:11pm

There is an interesting thing happening at the moment though. We all know that Java EE 5 got its inspiration from open source software like Spring/Hibernate. But today, things are changing. Spring 2.5 is getting its inspiration from Java EE 5 (less XML and more annotations), Seam is working hand in hand with Java EE (Seam will be WebBeans in Java EE 6).

Using Spring over J2EE 1.4 was like a breath of fresh air. But today, when I look at a Struts/Spring/Hibernate application vs Java EE 5, I don't understand such complexity :verbose ioc, low level mvc framework, xml wiring, xml orm mapping, struts-config.xml, more xml, HowLongYouWantMeToTypeMySpringClassName (I forgot Abstract in the sentence)...

J2EE 1.4 left us with bad legacy design and patterns. When we say that Java EE is complicated, it's not just because of the amount of specifications. Our architectures need such complexity, so we need a specification to answer this complexity : we were not doing Web Services 5 years ago, now we are, so we need a spec; Java EE 6 will introduce a Resftul specification, because that's what we are starting to do.

What made J2EE 1.4 complex was also the all Pattern thing (DTOs everywhere, DAOs, Delegate, UniqueIdGenerator, ServiceLocator...). Now I still see plenty of Java EE 5 projects using the same patterns. That's why people say Java EE 5 is difficult. It's because we got used to a certain type of architecture (Entity Beans were not serializable, that's why we used DTOs), and we have to rethink that today (it's not that bad to use a JPA bean on the client side if needed). When you see an application with domain objects, DAOs, ORM mapping, Spring services, XML wiring, DTos, Struts form, struts-config, Struts actions and JSPs... god, how much more complexity can we handle.

It might sound strange to ear (because we've been saying the opposite for long time), but Java EE 5 applications (JSF/EJB3/JPA) are easier to write than a Struts/Spring/Hibernate one. And because we are talking about standards, tools are getting really powerful.


I can bang out a web app with JPA/EJB 3.0 in NetBeans and deploy it in GlassFish (without writing any XML) and you still be wiring your Spring beans ;o)

Alexis MP replied on Wed, 2008/01/30 - 4:15pm in response to: Siarhei Dudzin

@svadu: GlassFish is not your father's reference Implementation. Just give it at try. You might be surprised by the management tools, the clustering or the performance. Some early success stories starting to show up here:


David Sills replied on Wed, 2008/01/30 - 8:38pm

A number of well-taken points. I have to admit I'm only now getting 'round to EJB3, which seems amazing to me after EJB2. Even Spring, which I've taken to, has things to learn from it (and they are doing so, as noted above).

I still like Spring just fine and I'll continue to use whatever I think best serves my clients - my usual concern has changed from not wanting to be too far behind with technology to wanting to leave my clients with something they can really maintain. The move in the Java EE space from XML to annotations: good. The move from JSP (enough like classic ASP that even M$ies can follow it) to facelets: not so much. Not that there's anything wrong with the technology: on the contrary, I like the idea. But there's an awful lot of magic, which tends over time in my experience to be hard to maintain. Not to start a flame war: if I had the right client I'd take up facelets in a second.

But for me Java EE 5 is a step in the right direction, and the fact that Oracle AS took it up early and reasonably well is a big plus for it (again, to my clients). Not that there aren't still teething problems, but that's true of everything (note the RMI issues mentioned above!).

I'm keeping my mind open about everything until the landscape clarifies itself and keeping up with Java EE 5 and with Spring (and watching Seam and Wicket and ...).


Nicolas Martignole replied on Thu, 2008/01/31 - 5:52am

Very good article.

I only hope that teacher in University did the switch to JEE 5. A beginner should learn directly JEE 5 and that's it.

I checked this morning in a Technical Training Company that works with us:  there's still some training about "J2EE 1.4 with EJB2.1". Believe it or not, some people still makes a lot of money on top of this poor J2EE 1.4... Let him rest in peace



Siarhei Dudzin replied on Mon, 2008/02/11 - 6:21pm in response to: Alexis MP

[quote]@svadu: GlassFish is not your father's reference Implementation. Just give it at try. You might be surprised by the management tools, the clustering or the performance. Some early success stories starting to show up here:



I am not talking about myself I meant it in general that it may not be adopted as fast as it deserves just because of the bad name of the previous reference implementation (a situation similar to J2EE - JEE5 btw). As for me I've made my choice...

PJ Murray replied on Sat, 2008/03/08 - 4:10pm

One reason for the the slow take up is that development managers are a lot more weary now about using application servers (or anything else for that matter) that are not battle tested..... and of course, the pull great alternatives like the Spring framework.

Pyros Vallum replied on Tue, 2008/03/25 - 11:40am

In response to Antonio's last post:


"It might sound strange to ear (because we've been saying the opposite for long time), but Java EE 5 applications (JSF/EJB3/JPA) are easier to write than a Struts/Spring/Hibernate one. And because we are talking about standards, tools are getting really powerful."


That is so true. I wrote a media rental system for a local business in 15 hours (approx). I used NetBeans, MySQL, and Glassfish with some JSF (which is great by the way - read the JSF chapter in Apress' Beginning Java EE5 - it's brilliant!). Am I a noobie? Hell no! I used to teach the FJ310 course for Sun Microsystems UK about 4 years ago. J2EE 1.4 was absolutely hopeless, so many xml files, empty boiler-plated methods and DDs to make you puke with depression. And don't get me started with the Remote/Home Interfaces. Argh!

But with Java EE 5, I was asking myself "Is that it? Is that all I need? @EJB? @Stateless? Wow. So I'm hooked.
the latest Sun course teaches you how to do it.

At the moment, I'm working with a company who have got this JavaScript/Spring/Hibernate/extJS/JSON/DAOs/DTO/spring.xml/ORM/literal-embedded-object obession going on which is driving me mad! It's like they're actively avoiding everything Java EE 5. It's just irritating - so many freakin' layers! I've created a dialog in ExtJS which has taken a week! A WEEK! Weaving everything together to make a multilayered mess! I could have written this dialog in Swing in 5 minutes!

Java EE 5 rocks.

Ash Mughal replied on Tue, 2011/12/27 - 1:49pm

I'm not sure if really nobody using JEE5 but at least we are using it as main development platform. We are using Glassfish (amazing app. server) and JSF for web development.
Yes it is true that EJB was evil term but the new spec. did relief lot of work.
Many still complain a lot but IMHO they need to try it (really using it, not just a few "hello world") before taking conclusion.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.