Adam Bien's Weblog

Why I Like EJB 3.0 And Really Like EJB 3.1, Or EJB 3 Killed The XML

Marc Fleury wrote a readworthy Blue Paper "Why I Love EJBs" in 2002 (download), which for that time was really surprising. I worked already with EJBs that time, but didn't really loved them :-). I wouldn't go so far either, but I really like EJB 3.0. The reasons are:

  1. The performance overhead is low. In Glassfish v2 only about 3%.
  2. EJB 3.0 are thread save. This is a huge benefit. Every thread gets an own instance - also all injected resources (Entity Manager, Data Source, JMS) are thread save as well. The best of all: the container manages the resources for you. Only an annotation is required (@EJB for EJBs, @PersistenceContext for Persistence and @Resource for remaining resources :-)). Just try it with "plain old Web Container" :-). Hint: Servlets are thread-unsafe singletons.
  3. EJB 3.0 are transactional. So in case the method invocation is successfull, all resources will be synchronized (data written to DB, messages sent to server). The container does it for you - you have only know what you would like to achieve (this is platform independent, but sometimes hard enough :-))
  4. In all of my projects we get rid of deployment descriptors and used annotations. Only a lean persistence.xml was deployed. Refactoring, deployment and portability just worked well.
  5. EJB 3.0 are really portable (and so vendor, framework neutral). There is lot more specified, than EJB 2.1 days - so proprietary deployment descriptors aren't needed any more. Actually no descriptors are needed. You only have to deploy one clean jar, with persistence.xml in meta-inf. Everything else is optional (and somehow suspicious).
  6. The synergy between Convention Over Configuration (or officially: Configuration By Exception) and Dependency Injection is great. Actually in most cases you get with EJBs less code, than without (no "new" invocations, just declarations).
    public class SampleBean implements Sample {
        private EntityManager em;

        private Another anotherBean;

  7. Getters And Setters are optional: for EJBs, as well as for JPA. It's your decision. Resources can be directly injected into the fields.
  8. The defaults and annotation configuration can overruled by XML-descriptors. The XML descriptors do not have to be complete - only interesting portions can be specified. You can easily override the production settings for e.g. staging (test, integration etc).
  9. Actually there is no special tooling required. You only need the annotations, a Java 6 compiler and a Jar. However the support in IntelliJ, Eclipse (with 500 additional plugis :-)), or Netbeans 6.1 are really superb. The applications servers are already well integrated - deployment, undeployment, configuration etc. can be managed directly from the IDE.
  10. EJB 3.1 will be embeddable out-of-the box. However Glassfish v3 is already emeddable. I'm testing now the WebContainer - it's surprising (starts in 500ms).  JBoss is embeddable as well.
  11. EJB 3.1 will come with a lot of useful features: Singletons (good for configuration, startup classes etc.), better timer support (cron-like), async methods with Futures, optional local-interfaces and WAR-deployment.
  12. Pool settings and thread pool configuration is really useful to control the scalability (and not scale indefinitely until the container crashed :-))
  13. They play well with scripting (JavaScript, Groovy etc.)
  14. EJBs are managable and monitorable by default. You just deploy them into container - and you can monitor the method invocations, performance etc.
  15. No additional frameworks, libraries etc. are needed first. The ejb-jar and the container only contains your application code. So NoClassDefFoundErrors, ClassCastExceptions etc. can be minimized.
  16. EJB 3.0 are ultra-lean. You actually cannot take something away :-). However: I'm open for suggestions.
  17. They are really easy to test - it's just class with an interface. You can even start them outside the container.
  18. Even simple use cases can be efficiently be realized with EJB 3. See e.g. CRUD:
    public class CrudServiceBean implements CrudService<Integer,Customer> {
        private EntityManager em;

        public Customer create(Customer t) {
            return t;

        public void delete(Customer t) {
            t = this.em.merge(t);

        public Customer find(Integer id) {
            return this.em.find(Customer.class, id);

        public Customer update(Customer t) {
            return this.em.merge(t);

  19. ...and they really work well: I'm using EJB 3.0 + JPA 1.0 since about 2 years in projects. It worked not only surprisingly well for me - the team members were surprised as well.

However there is still room for improvement in the Java EE 6 Platform. JMS spec could be easily redesigned to be more "fluent". The JNDI registry is archaic. Fixing/simplifying the JNDI-API would be really beneficial not only to EJBs, but for the whole platform as well...

NEW workshop: HTML 5 and JavaScript Essentials, Three days in April 2017: from Java EE 7 Architectures over Microservices to Performance, Troubleshooting and Monitoring
On demand workshops: Java EE 7: Bootstrap, Effective, Testing and Microservices available for streaming.


A book about rethinking Java EE Patterns


I'm looking forward to being able to host EJBs in the web container inside my .war file. That feature, singleton beans, and the newly usable timer service were really badly needed. I find it unnecessary to put my EJBs into a separate project, then create a common jar for classes that will be passed in and out of it (such as a Customer object), then bundle them into an EAR. I think that is the unnecessary complexity people still talk about.

Posted by Ryan on June 12, 2008 at 05:46 PM CEST #


you are absolutely right - I forgot to mention the packaging. But it's my blog, so I will change the entry :-),



Posted by Adam Bien on June 12, 2008 at 05:52 PM CEST #

I think the trend to get rid of all this error-prone XML configuration files is on of the most important change in JEE ecosystem.

Posted by Adam on June 14, 2008 at 05:08 PM CEST #

Hi Adam,
... proprietary deployment descriptors aren't needed any more? I am not sure.

I think the standard descriptors are replaced by annotations but not the mappings of resources used in the code to real resources in the platform like JDBC datasources, JCA connection factories, JMS queues.

Best regards

Posted by Anton Vorsamer on June 02, 2009 at 03:41 PM CEST #

Hi Adam,
I tried to download the paper of Marc essay but got 404.

I searched the net but I couldn't find "blue.pdf"...or my search skills are horrible ;)

Would you mind posting again the link


Posted by Christos Vasilakis on June 29, 2009 at 05:27 PM CEST #

Hi Adam
I have been using EJB3.0 for a while using Glassfish v3, but whilst developing under Eclipse, I can not see the javax.ejb.Singleton class in the jar.
Do you know where I could get the latest JAR file, without having to download the entire Glassfish (seem to have the latest of that anyway).

Posted by Keith on November 11, 2009 at 12:09 PM CET #

You say: "EJB 3.0 are thread save. [...] Every thread gets an own instance - also all injected resources (Entity Manager [...])."

How is thread safety implemented with @PersistenceContext? The injection is performed only once at creation time, but the injected resource will then be used be multiple clients.

Is the injected EntityManager a proxy with a threadlocal implementation?


Posted by Christian on January 07, 2010 at 11:58 AM CET #


there are many ways to implement that. EntityManager is not the issue, rather than its transactional cache.

I guess most of the implementations provide a distinct cache for every transaction, what is in the EJB 3 case also a thread. As I said: EJB 3 do solve the problem for you :-).



Posted by Adam Bien on January 07, 2010 at 04:51 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
...the last 150 posts
...the last 10 comments