Adam Bien's Weblog

Heavyweight EJBs, Lightweight POJOs, Ultralightweight EJB 3.X, and the Demise of POJOs

From time to time I meet someone who doesn't like EJBs :-). He often argues: "EJBs are heavyweight". This is in general enough to convince developers, not to use it. However I often ask in such situation: "Please define the term heavyweight and lightweight". I love the answers. In most cases the term "heavyweight" is associated with container, deployment and frameworks. Recently I got even an answer, that EJBs are annotated - that the reason for their heavy weight. I asked than, whether it would be lighter to have a deployment descriptor - but the discussion stopped at this point :-). Even the description in wikipedia is funny: "...EJB 3.0 was less heavy weight than EJB 2.0 and provided more choices to developers...". So EJB 3.0 are less heavy weight - than I would like to introduce the term "midweight" :-).

The truth is: EJB 3 are just annotated Java classes (if you love XML you can even use just Deployment Descriptors instead of annotation) - but the container (=runtime - still not need to associate the term "container" with heavyweightness), uses the meta data to add additional behavior during the deployment time. The additional behavior is nothing else, than aspects - or crosscutting functionality. Some of the aspects are essentially important in concurrent systems. Especially the association of an instance with the thread, and transactions are really important. The problem here: both are unsexy and do not have effects on the "green bar" in unit tests - so this issue is often ignored (until production :-)).

Because of the aspects, we get indirection between the caller and the instance. The aspects (nothing else than decorators), are executed first, before the actual instance (business logic) will be executed. So the container applies, transactions, checks the security starts a session in case needed / declared. This causes of course some overhead (3% in Glassfish) - but you would have to provide similar functionality anyway.  In case of pure POJOs in a WebContainer, you will have to provie a ServletFilter, decorate the request with security, transactions etc, instantiate all needed / required resources in the filter, put them in a ThreadLocal, catch all exceptions and rollback transactions ....and educate the developers only to use the resources from ThreadLocal.

Applying aspects to POJOs could be actually a reason to call EJBs "heavyweight". But then, all other frameworks will have to be renamed as well :-). One real issue with J2EE were overblown (often commercial) appservers. The deployment was slow and errorprone. However this issue is already solved (the download of Netbeans 6.1 with Profiler, Visual Designer, Tomcat 6 and Glassfish v2 takes 139 MB) and is getting even better. A deployment of a small EJB 3 takes about 2 seconds on my machine (without virus scanner :-)), bigger applications can be deployed in less than 1 minute. The only thing, which takes long ist the preparation of NamedQueries in JPA - but this is an EJB 3 independent issue. Glassfish v3 is highly modular and embeddable. JBoss - was always modular - and is embeddable as well.

So, what's the deal with "lightweightness"? If you ask me, EJB 3 are "ultralightweight", and POJOs actually silently disappeared. The "POJOs" are often nothing else, than JavaBeans maintained by another container, using similar techniques. Pure POJOs, without decoration, configuration and aspects are gone (or are only usable in applications without concurrent write-access to database). Even ultra-lean (and really great) Guice, will have to decorate POJOs with transactions, concurrency, inject resources etc. Perhaps we should rename EJB 3 to another term - the same story as with applets - the problem with the history :-)

NEW online workshop: WebStandards Igniter (online)

Airport MUC workshops: Java EE 7: Bootstrap, Effective, Architectures, Web, React and Angular, Testing and Microservices


A book about rethinking Java EE Patterns


IMO, the real problem was conceptual weight in the early EJB specs. Too many new concepts to learn. It's a basic human principle: "if you have a hammer, you will use it". Servlets were good enough, why go learn a (very big) new spec.

EJB 3.0 is a big improvement, and so is EJB 3.1. Now if we can just get it digested into an easy to use implementation and a small spec for EJB3.1.lite, we will see a big change in adoption.

IMHO, etc...

Posted by Eduardo Pelegri-Llopart on June 15, 2008 at 11:32 PM CEST #

I have other gripes with EJB than their weight (or lack thereof). To me, as a developer of frameworks and more or less generic components used by many developer teams, the JEE spec lacks a great amount of stuff once you go beyond the usual business logic + some database type of application.

Clustering ? Not even mentioned in the JEE spec. Cluster membership (have a cluster node uniquely identify itself), sending messages to all cluster nodes (have to resort to proprietary replicated JMX), etc...
Execute initialization/warmup code at startup ? Still have to resort to the servlet trick, or use proprietary mechanisms.
AOP ? Dependency Injection ? only very lightly supported in EJB 3.0, clearly not sufficient for more complex approaches.
Security ? JAAS ? ouch.

To me EJB is a great facade technology for remoting, EJB 3 is a nice managed component model for applications where it fits... business logic, JDBC, web or Swing UI, but nothing more advanced (from a purely technical point of view) where you need a lot of flexibility or cluster awareness. And yes, while Spring doesn't help wrt clustering, it provides a much more flexible and fine-grained model to manage beans. I mean, this isn't theoretical or fanboyism, I clearly encounter situations where a fine-grained control is needed, every single day. So while EJB can be a good approach for business application level developers, especially when you need to fence them into a scarce technical frame, it just doesn't provide enough features nor flexibility for frameworks or components that need a fine grained control over lifecycle/deployment, cross-cutting concerns (security, audit logging, ...), clustering, etc.
Where's the BeanPostProcessor in the EJB spec? :)

Posted by Pascal Bleser on June 16, 2008 at 11:59 AM CEST #

My reply, as your blog doesn't allow more than 1000 characters for comments ;)

Posted by Pascal Bleser on June 16, 2008 at 12:03 PM CEST #

Hi Pascal,

...and I can only post comments to your blog having a Google ID :-).

Most of the stuff is addressed in EJB 3.1 (startup etc). You are right, EJB 3.1 do not solve every problem - but are really enough for 80% of all use cases. You can still use whatever you want on top.
Thank you for the detailed comment!,



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


thank you for your comment! IMHO you are semi-right :-).
The EJB 2.0 was actually easier, than EJB 3 - because there was less specified. The real problem were CMP 1.0 - there were just conceptually wrong (fine grained remote access). CMP 2.0 were to dependent on API and not powerful enough. However this was fixed with JPA 1.0.



Posted by Adam Bien on June 16, 2008 at 12:57 PM CEST #

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