It is my perception that whenever new JEE projects start (where these technologies would be applicable), people prefer to use a combination of Spring + Hibernate instead of EJB 3.

It seems junior programmers are even advised to go for that instead of EJB.

Is this personal preference or are there pertinent reasons for it? (e.g. personal scars created by earlier EJB versions which caused mistrust in EJB or technology bloat versus performance reasons or learning curve)?

  • 2
    I almost think it's a historical carry over because ejb wasn't as good as spring+hibernate at one point...now I think a case can be made for ejb in some cases... – Rig Feb 17 '12 at 12:58

The EJB 3+ frameworks are actually pretty good as they came along with JPA as an answer for annotation configured Persistence frameworks, as well as CDI which allows for annotation configured dependency injection. You also add on top of that Weld. Spring on the other hand is just now catching up in the game with configuration through annotation.

With that being said the historical backlack against EJB1 and 2 should not be discounted. They didn't just fail to solve the problems with writing enterprise applications, they spectacularly failed. It was a complete failure on the part of the designers to get a pulse on the true problems facing enterprise and web application developers and in turn deliver solutions that they actually needed.

Add on top of that the mistrust that there are some serious shakeups and instabilities with the current direction of Java at this time and lack of faith in the current stewards and owners of old Sun JVM, in Oracle. Many people do not have faith that Oracle will improve upon Java and lead the direction and there is also fear that the Apache Software Foundation may just throw in the towel. More and more people are looking to OpenJDK for the future of Java but it just isn't where it needs to be for Enterprise adoption.

Some see all of this as the smell of death as enterprise applications are the leading reasons why Java has historically been the #1 programming language in the world for as long as it has. This is why Microsoft has been gaining so much ground against Java with .NET technologies.

The non enterprise based Java application developers are turning more and more towards OpenJDK and other open source frameworks to help build their solutions and some are never looking back. One could say it is a case of too little too late on getting JEE back in the forefront of legitimacy, even though technically JEE can and does stand toe to toe with your comparable Spring application.

  • Well summarized and spoken marple. This shares my sight of EJB too. – onigunn Feb 17 '12 at 14:29

EJB has a lot of baggage. Part of that baggage comes from the fact that it was targeted at the wrong audience. The other part was that the first two versions were utter crap.

If you look at the original EJB versions, the design was that an EJB developer could create a packaged solution that could be used within any EJB compliant container. For an in house shop, this level of abstraction was unnecessary. It was a perfect solution to make a thriving market for third party EJB component vendors. However, the Container vendors were overzealous in their marketing and were making tons selling their product as a viable solution for every day development. This would be the equivalent of building all of your application code as COM+ components.

For more of the background on the original J2EE spec, most of the vendors involved had CORBA servers and wanted to leverage those products going forward. The EJB spec was built over the IIOP protocol (actually Java RMI which was a thin layer over IIOP). CORBA had already been rejected because of its complexity, and EJB was just CORBA in disguise so it brought with it many of the problems that CORBA had. Actually, the abstractions of EJB made it more difficult to work with than a pure CORBA implementation would have been.

Once the rubber hit the pavement, people realized that performance with EJB was atrocious. With every call being a remote call and the difficulty of even getting the application up and running correctly to begin with, people quickly looked for alternatives. Hibernate and Spring running in a JSP container became the solution.

EJB 3 "adopted" this approach. But it's still a generic compromise that doesn't provide much benefit. There is still no 3rd party EJB component market so there's really no point in using an EJB container to build your solution.

Long story short. While EJB 3 is a vast improvement over the first two iterations, it still doesn't provide enough benefits to outweigh the costs.

  • This would be the equivalent of building all of your application code as COM+ components. ... How horrifying – maple_shaft Feb 17 '12 at 14:43
  • 3
    Exactly ;) I worked with a dotcom back in 2001 that decided they were going to port their PERL application (that was working just fine mind you) to J2EE. The "architects" for this effort had a collective one month of J2EE training (having never written a line of Java prior). My favorite quote "Well I'm really good at PERL, picking up Java is a matter of just learning a new syntax." I submitted my resume to Monster that day. – Michael Brown Feb 17 '12 at 15:15

Your Answer

