Java Champion / JavaOne Rockstar Adam Bien ( is a self-employed consultant, lecturer, software architect, developer, and author in the enterprise Java sector. He is also the author of several books and articles on Java and Java EE technology, as well as distributed Java programming. adam has posted 59 posts at DZone. View Full User Profile

Java EE - Where is the Real Bloat?

  • submit to reddit
Developers still complain about the breadth of J2EE and Java EE and sometimes about the extensive specification. J2EE 1.4 and Java EE 5+ are actually only a release of independent APIs. Servlets (JSF or another Servlet-based framework), EJBs are the the only "executable" components which are intended to use APIs like JTA, IIOP JMS, JCA, JDBC, JPA....  

As a Servlet / EJB developer you don't have to know these additional services, you can go with your business logic only. In this case you will only have to learn the Servlet (or a web framework of your choice) and the EJB component model. Servlets and EJB 3.X are very simple (you can build a simple app in few minutes), a web framework can be as complex as you like, but it was your choice. You still don't have to use a single "enterprise" API to develop an application on a Java EE server, but if you have to they are ready to use.

Lets consider the remaining APIs:

  • JDBC - a stripped down version runs on Java ME, even together with JavaDB
  • JMS - there are implementations (even from application servers considered as heavyweight), which run on embedded devices.
  • Servlets - Java Card comes with built-in Servlet support
  • JPA - nothing prevents it to be executed on an embedded device
  • JTA - the jini framework came with 2PC and transactions semantics and was considered to be used on embedded devices as well. Btw. JTA API is probably the simplest one. With EJB 3.X you are even not intended to use it programmatically.
  • EJB - the Glassfish v3 container is about 1MB, JBoss, WLS about the same size. 
  • JCA - actually some J2ME persistence APIs (e.g. FileConnection) are very similar to JCA
  • IIOP - it actually take offs in the embedded space. It turns out, that it is very efficient for embedded communication (and was considered as too heavy for J2EE :-))

It seems like the APIs itself are not the problem, rather their implementation. As a vendor you can put an unlimited amount of bloat into every of those APIs. And it happens on regular bases. Recently I had to deploy a single EJB on a, well known, application server with a commercial IDE and had to provide an incredible amount of settings and tweaks. But they had nothing to do with Java EE and were vendor-specific. To demonstrate the difference, I copied exactly the same ejb-jar into Glassfish, then JBoss and it worked perfectly in both cases - without any strange settings.

Java EE isn't actual the real problem, rather than proprietary vendor extensions and additional services, which not only increase the complexity, but could lock you down to a single vendor. As long an API-implementation only sits on your disc and waits to be used, it doesn't increase the complexity.

Glassfish v3 e.g. is capable to load and unload EJB 3-container as an OSGI-bundle on demand. This would mean in that case: a Servlet application with loaded EJB 3 container would be more complex, than the same app running on the same Glassfish with deinstalled EJB 3-container - from my point of view it makes no difference...

I cannot wait for the first bloated OSGI servers, with millions of bundles and services. The first one is already on the horizon. 

Btw. the Java EE specs are really good. Very useful to be used as an index to lookup things...

[The first chapter in "Real World Java EE Patterns - Rethinking Best Practices" book explains Java EE basics and a bit of J2EE history.]
Published at DZone with permission of its author, adam bien. (source)

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


Michael Riecken replied on Mon, 2009/07/27 - 12:09pm

I grow tired of the overly casual writing style found on dzone.  Could the editors please proof for:

  1. Sarcasm

    For example, "I cannot wait for the first bloated OSGI servers, with millions of bundles and services."  I assume that this is sarcasm.  If not, I am uncertain of both the author's sanity and point.
  2. Broad Generalizations

    For example, "Developers still complain about the breadth of J2EE and Java EE and sometimes about the extensive specification."

    I don't complain and I am most assuridly a developer.

    If a specific subset of developers are complaining, it should be specified.  For example: "The majority of the developers who posted comments on the J2EE formums on complained about ..."
  3. General grammar, run-on sentences, incomplete sentences, etc.

    This is no slight on Adam here, I am sure that he is a bright guy.  It is the editor's job to ensure that he comes accross that way.
To the meat of the article,  I agree;  there's a ton of FUD surrounding the size and/or scope of a J2EE implementation.


Reza Rahman replied on Mon, 2009/07/27 - 1:01pm


Firstly, excellent article - I agree with you a 100%. A handful of bad implementations most certainly have a lot to do with the bad rap Java EE has received over the years. It's also hard to ignore the fact that the EJB 2.x (specifically 2.x Entity Beans) programming model was pretty cumbersome/heavyweight.

I do think most informed developers already know that the bloat is a thing of the past, especially with very focused Java EE 5 implementations like GlassFish/JBoss 5. Hopefully the upcoming Java EE 6 Web Profile, pruning, Java Contexts and Dependency Injection (aka WebBeans) and EJB 3.1 Lite will convince a few more developers that all that can be conceivably done to keep Java EE as simple and streamlined as possible is being done wholeheartedly.

I am currently working on Resin's EJB 3.1 Lite container and think Resin is a great example of the next generation of Java EE too. The Resin folks have always taken pride in keeping Resin as lightweight as possible, so hopefully we can all look forward to a decidedly lightweight, painless Java EE 6 Web Profile compliant application server in the form of Resin. Interestingly, the Resin folks have already looked at OSGi and bypassed it as a technology that is very promising but not all that applicable for most bread-and-butter Java EE applications. Take a look at "Why OSGi is cool, but not for most enterprise apps":



adam bien replied on Mon, 2009/07/27 - 2:34pm in response to: Michael Riecken

Regarding 1: it isn't sarcasm, actually a prediction.
Regarding 2: If you are not complaining - then you got my point. I should rephrase that - but I'm constantly confronted with the questions about bloat etc. in my project.
Regarding 3: You are actually right regarding the grammar etc. I was asked to give away the content from my blog from time to time by the editors - and I agreed. So this article is only a quick hack from my blog ( and was "intercepted" by dzone - it was never meant to be an "article". I spend definitely more time on articles.

Thanks for agreeing with me.The meat is: if you take any other technology in distributed context, you will end up with similar set of services and APIs - slightly differently packaged.

Liam Knox replied on Mon, 2009/07/27 - 4:56pm

I will give you my own prediction. EJB and this flavor of J2EE is very much dead. I think Spring has proven technically and via its adoption that EJB's are not needed, further more whether the concerns that are being addressed are better handled via a framework or container.

Sure EJB 2.1 permantly damaged EJB's reputation, though I havent really seen much of the later offerings being much more that trying to align something to the POJO world which is a affectively it is not.

I cant really see any longtern future for the tranditional J2EE appliction server model.

On OSGi and modularisation, I think that is a very different topic that is yet to play out in full.

Nitin Bharti replied on Mon, 2009/07/27 - 5:15pm in response to: Michael Riecken

Michael, regarding grammar (and with all due respect to Adam), I agree, we could do a better job polishing blog entries prior to republishing them.  Moving forward, we will make sure this is a part of our process and that contributing DZone bloggers sign-off on any editorial and grammatical changes made by our editors.


Nitin Bharti

Publisher, DZone



Reza Rahman replied on Mon, 2009/07/27 - 8:31pm in response to: Liam Knox


You are of course entitled to your opinions (as for me, I tend to stay away from predictions altogether - they tend to have a built-in quality of Hubris about them). The prediction you speak of is hardly new or original though (or speak to the content of the article for that matter). The reality is that Java EE adoption continues to rise despite all the naysaying. Indeed, I see more EJB/full stack Java EE adoption now than I have seen at any other point in my career. In the mythical "golden years" of J2EE picture some people like to portray, I hardly saw anyone deploying EJB beyond some very large corporations. These days, I see mid-sized companies and even startups giving serious thought to full stack Java EE adoption (albeit often with JBoss Seam - a good bit of which is being standardized in Java EE 6). Just some things to think about before making too swift of a generalization...

I also beg to differ on your assertion that an EJB does not meet the definition of a POJO or that frameworks are necessarily better than platforms universally. I think both of those statements are a little out of balance :-). I do agree that the OSGi story is yet to play out fully. With respect to Adam, I do think the statement on OSGi could have been phrased better (then again, who amongst us can claim to never have mis-phrased something - I most certainly have).



adam bien replied on Tue, 2009/07/28 - 4:32am in response to: Liam Knox

J2EE is dead, but Java EE 5/6 rocks. Regarding the EJB 3 adoption: at least in Germany / Swiss / Austria it is great. Btw. we (Juergen Hoeller and me) already agreed that EJB 3 and Spring architectures are almost identical - you could even tweak Spring to "understand" EJBs very easily.

Andrew McVeigh replied on Tue, 2009/07/28 - 5:04am in response to: adam bien

>Regarding 1: it isn't sarcasm, actually a prediction

it reads as both sarcasm and a prediction.  the two are not mutually exclusive.

it's hard to read "I cannot wait for the first bloated OSGI servers, with millions of bundles and services" without seeing an element of sarcasm and shadenfreude. Not that I care, I don't really have a foot in either the OSGi or JEE camps.  I'm just deconstructing the text.

On way to phrase this without the overtones a more straight-forward construction like:

"I predict that the OSGi servers, when they arrive, will be bloated with many bundles and services in a way which makes JEE look light".

I'm guessing that's what you meant?



Gérald Quintana replied on Tue, 2009/07/28 - 7:49am

IMHO, at the moment, the strengh of Spring over Java EE is automated unit testing. To test EJB3 Session beans you need 

  • Either do "in container testing" (ala Cactus), but it's painful and ugly
  • Or have an embedded JavaEE container (JBoss and Glassfish can do that), but configuring it may be complicated and starting/stopping before/after each test may be slow
  • Or simulate a JavaEE container with other technologies (EJB3Unit, Guice, Spring...), but you won't get the real container behaviour

adam bien replied on Tue, 2009/07/28 - 8:39am in response to: Andrew McVeigh

Andrew, well phrased :-). There are already commercial OSGI-based IDEs and servers available, which require you to run special hardware (not kidding). They are already bloated. OSGI is actually nice - but not a remedy for bloat. thanks!, adam

adam bien replied on Tue, 2009/07/28 - 8:43am in response to: Gérald Quintana

...or use: openEJB or even plain mockito :-). Testing EJB 3 is actually very efficient - even without additional tools or frameworks.

Reza Rahman replied on Tue, 2009/07/28 - 8:45am in response to: Gérald Quintana


Give OpenEJB or EasyBeans a try for unit/integration testing: That's what I use for my Java EE 5 projects. The startup and shutdown has typical performance in the sub-second range. I am told the JBoss folks are working to scale down the Embeddded JBoss tool once it gets out of beta mode (which it is still currently in). I would imagine the GlassFish folks will do the same when they become Java EE 6 compliant and their Embedded tool is productionized. And there will be choices from the WLS, IBM, etc camps too since embedded containers are part of the Java EE 6 standard (and of course Resin will have a solution too :-)).

Configuration complexity is of course a more subjective topic. Most developers that work with Java EE 5 state that working with it (unit testing included) requires a lot less configuration effort and it has a much smoother learning curve. Both of these factors can be traced to the fact that Java EE is a cohesive platform focused on solutions for the 80% use case rather than providing options and features that cover edge cases...

Hope it helps,


Reza Rahman replied on Tue, 2009/07/28 - 9:00am in response to: adam bien


Fantastic material on the blog, especially the Spring/EJB 3.1 analysis piece. Again, I agree 100%. In fact, before I decided to contribute to Resin, one of the projects I was seriously thinking about was creating a Spring - Java EE/EJB 3.1 bridge. Maybe someone else will pick up on the idea (hint, hint) :-). The SpringSource folks were actually willing to host the project, but did not want contribute resources to it other than that :-(.



Ibrahim Levent replied on Tue, 2009/07/28 - 9:21am

I think we need a simplification layer(A super set of current Java APIs) on top of Java EE. This is not going to be a new language, it would be an API set with an integrated suite of frameworks. Java EE is really huge for an average or entry level programmer. This new layer should cover all aspects; persistence, transaction management, logging, web flow, presentation, js library(for web development), messaging and reporting. This approach would be as simple as to use VBasic but in Java language. It would terminate the the pain to integrate many many type of frameworks(Once The Lightweight Libraries) or Java technologies. We use such an approach in our ERP development project. We eased to use the Java platform for application developers. Architects still have to understand the Java platform in detail to provide simple API set but not the all developers. Just an example, look at the following code piece:

FSLogFile file = new FSLogFile("mylog.txt");
file.append("This is a log!");

There is no stream, no IO API, no IO buffer, no resource release, no new language. It is so much easy that any developer could use without any problem.

This simplification can be done in every layer of Java EE. But this is a very huge work that may require a very big effort(We're currently working on such a project). It is going to be the "Integrated Java Development Platform" like .Net (Limited choices for the sake of simplicity) and it won't restrain current freedom of platform or implementation selection. It would just make Java EE richer by increasing productivity.

Reza Rahman replied on Tue, 2009/07/28 - 9:45am in response to: Ibrahim Levent


Sounds promising, do hope you keep it up. In case you haven't looked at it yet, JCDI (JSR 299) might help you with the effort: Although JCDI is targeted for Java EE 6, the goal of the JSR is to be able to create pluggable implementations that can run on top of Java EE 5. You could actually consider simply donating your code to the Apache or JBoss JSR 299 implementation: (or maybe even Resin's JSR 299 implementation :-)).

A few years back, I was really hoping Spring would do exactly this. Indeed, some of the Spring template APIs do this fairly well and can cleanly be integrated on top of Java EE 5. I think they have gotten a little too carried away from that focus into the often virulent/counter-productive anti-Java EE mind-set. Sometimes I can't help but think the unneccessary negativity has made them into what they once hated, but that's another story. I keep hoping that will change at some point, but it is obviously up to them. Personally, I've given them my support in incorporating the Rod's DI JSR (JSR 330) into Java EE 6 and have kept open arms/open mind.

Best of luck,


Liam Knox replied on Tue, 2009/07/28 - 7:08pm in response to: adam bien


Please see the adoption of Spring in the Fortune 500 companies , relative to any Glassfish, JBoss or any other container based solution. You will find the adoption of these technologies are massively on the wane and Spring on the up. That you and Juergen agree is nice but I assure you he is humoring you to a certain extent. Springs mission is not to be some EJB or JavaEE implementation, but to be the platform for the enterprise. There is no profit nor reason in sticking to a benine community driven direction if it does not work. Springs adoption came from that fact it delivered a framework that worked against what was 'perscribed' to be the only way to work, that didnt work.

Why would you want to 'tweak' Spring to undestand EJBs ? Why would you want to use EJBs in the first instance?

I will stick on my stance from experience 1. I was burnt by EJB 1 to 2.1. I saw companys reduce entire applications to a single bean before realising the technology didnt work and shooting it. I have seen rediculouse build, release cycles and intractability to test. I have since seen zero adoption in any company I have worked in since or from colleagues who I have talked to. I have seen vast articles on EJB 3 now 3.1, compared these to Spring and have worked they dont add anything ,rather they add complications, and I have seen the overall adoption pattern moving toward Spring, see Job trends.

This is the world today. I am not sold on OSGi personally and have little need for it todate. Perhaps something will trump Spring in the Enterprise , perhaps something will trump Java, but one thing I am certain of it wont be anything dressed up as J2EE , JavaEE or whatever reinvention they coin.

Liam Knox replied on Tue, 2009/07/28 - 7:27pm in response to: Reza Rahman


Everyone predicts, I would question a human that didnt have some predictive nature so dont try not to do it, it wont work anyway. Yes my prediction is not original but does that really add or negate its worth ?

On your adoption claims, can you site any evidence? I would be seriously interested. Personally I can site job trends data, company adoption data that counter this and the CV's of the candidates I interview day to day.

I think Spring has amply demostrated what a framework can do vs a container. Basically it can deliver the technical concerns and not take away the rapid development and testing cycle. Sure you can argue containers for live deployment, for example if you are OSGi alligned and require multiple lib versions and hot deployment, but this should not detract from the development cycle. The two are exclusive. EJB, JNDI, great examples of intractible, untestable, fragile technologies.

Reza Rahman replied on Wed, 2009/07/29 - 11:47am in response to: Liam Knox


I think you are beating a dead horse here. Yes, J2EE adoption is dropping (thank goodness). Java EE adoption is rising by all accounts. You are needlessly lumping the two together.

Frankly you are overstating the adoption case way too much. Firstly, check out Google trends. Spring just barely surpassed EJB as a job skill only a few months ago.That's not really saying much given that it's been around for quite a while, especially given pretty significant Seam/EJB 3 adoption. Secondly, job or adoption data in a given point in time really means very little in the technology industry that thrives on innovation, reinvention, disruption and churn. Take a look at the flux in everything from browsers, gaming systems, application servers, database servers, web framworks even operating systems.

Adoption is a red herring pure and simple, just one piece of the puzzle at best. In fact, adoption rates that do not change are good sign that innovation isn't happening, likely because of an oppressive (and hence malignant) monopoly. If I wanted a monopoly technology to work with, Java would not have been my choice, personally.

What really matters is technological merit. As I see it, Java EE is doing pretty well there thank you very much...



Michael O'Keeffe replied on Wed, 2009/07/29 - 10:46pm in response to: Michael Riecken

I grow tired of the overly casual writing style found on dzone. Could the editors please proof for:

I find it stunning that someone complaining about grammar manages to make 4 spelling mistakes, and an equal number of grammatical errors, in just a few lines.

Michael O'Keeffe replied on Wed, 2009/07/29 - 11:18pm in response to: Liam Knox

I will stick on my stance from experience 1. I was burnt by EJB 1 to 2.1. I saw companys reduce entire applications to a single bean before realising the technology didnt work and shooting it.

Sure, blame the technology. So the Spring-based project at a large insurance company X failed spectacularly because it was built on Spring? True, once they ripped all that stuff out, it worked fine, but the problem was more because some gee-whiz architects decided to springify everything, not realizing, like any technology, it should be used with care, where necessary. One thing they ran into was developers trying to debug xml instead of plain-old Java code. (That seems to me the prime deficiency in Spring. Would a Spring expert have such difficulty? maybe not, but looks like the training biz is as good for SpringSource as any of the EJB vendors, right ;)

I think it would be hard to name any technology out there that hasn't got it's share of bloat and missed expectations - Java, Windows, CORBA (the fear of this technology is as unfounded and naive as basing your fear of EJBs on painful experiences with EJB 1.0), Web Services (talk about bloat, take a gander at the WS-* specs), and, yes, Spring. Spring started out as a simple idea, IOC, now "it's much more than that" - sure is - we've got Spring batch, does transactions (like ejbs), so you gradually pile on all this missing functionality and voila, it's complex. And I'd really find it hard to believe that adoption of container-based apps is on the wane, considering Spring itself went in that direction starting some years back, after previously pushing the "look ma! no container". Take a look at their front page on their web site, it's all about Tomcat deployment. That's good, they have to adapt to the market.

Reza Rahman replied on Thu, 2009/07/30 - 8:01pm in response to: Michael O'Keeffe


Trying to look into the future is fine, but it is questionable to assert a dubious statements with certainty, particularly if the intent is less than honorable.

My experiences are the most important data point from my standpoint as to adoption. ~25% of my clients use Seam and/or EJB 3. They all report very good feedback. Spring adoption is good, but has barely surpassed EJB mere months ago and EJB still is pretty much holding ground. I also have a positive picture on the sales of both EJB 3 in Action and Seam in Action. It tells me developers are interested, despite FUD.

The Seam folks have even gone so far as to list their production projects on the Seam website. A listing for EJB 3 is possible but tough in the real world with multiple vendors and clients not necessarily eager in allowing you to advertise their names to the world, especially in this economic climate.

And all this despite the *years* of efforts to undermine Java EE with FUD and old, recycled arguments.

As to your point on testing/deployment cycles, please read previous posts. These things used to be true, they are not today, have not been since EJB 3.0 and certainly not true of Java EE 6.


Shaw Gar replied on Thu, 2009/07/30 - 9:25pm

One thing I don't understand about Spring is, if the customer has got a JavaEE server from a commercial vendor, Websphere for example, what would be the point in throwing away the EJB container and go for Spring? To question the benefits of standardization and disapprove of it , just because EJB 1,2.x were a failure is like throwing out the baby with the bath water.

Liam Knox replied on Sun, 2009/08/02 - 6:45pm in response to: Shaw Gar

For example, the EJB model didnt work in 2.1. The idea addressed concerns of persistence and remoting and they are not the core concern, rather it is how to configure concerns to work seemlessly. EJB always thought of things as black and white hence you got these idiotic ideas of J2EE bluerprints which were reallly 'the design is floored here are work arounds'.

If a vendor has Websphere, 2 things, 1. I am sorry they spent money on this, 2. they can and should easily use Spring in this enviroment to better address configuration, transaction and application concerns. I am sure the container will provide clustering and JTA if that is what is needed.

Liam Knox replied on Sun, 2009/08/02 - 7:01pm in response to: Reza Rahman


I dont really agree with you FUD contentions. The reason that J2EE, Java EE or whatever you dress it up as, is contencious in that it has failed the community since adoption. These concerns warrant acceptance and understanding. The 'old , recycled' arguments are in fact persistent concerns that the original ideas are fundamentally floored and these should be addressed. If you thing that EJB 3.0 or Java EE 6 are really going to address these then I think you are misguided. I think there are fundamental ideas within the specification regarding versioning and the ability to ugrade a given library that are fundamentally wrong. I would further argue that Spring and frameworks are what developers should be dealing with and the container is a seperate beast altogether. I do not think any of my statements are dubious in the least, and I will go out on wing to say Java EE 6 will be delayed and lower adopted than its predicessors, and Spring, for right or wrong. will take further market share

Regards Liam

Comment viewing options

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