Java EE and where is the real bloat?

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" explains Java EE basics and a bit of J2EE history.]

Comments:

Adam,

I agree, the problem is not the specs but the way vendors implement them and make them configurable.

But it's also about how developers use them. If for a simple HelloWorld-alike application you want to include the whole apache commons.* stack, mix it with spring and some other frameworks, well, then things might become bloated.

- Johan

Posted by Johan Vos on July 26, 2009 at 02:07 PM CEST #

@Johan,

exactly - Java EE isn't bloated by its nature, rather than the vendors, and sometimes the architects :-)

thanks for your comment!,

adam

Posted by Adam Bien on July 26, 2009 at 03:56 PM CEST #

As far as bloatware goes I think most developers would rather have more ways of solving a problem, rather than less. Honestly the J2EE stack makes it very easy for a developer to develop an application, while at the same time providing the ability for the Integrator, and Deployer of the code, the flexibility to deploy to many different environments, dev, test, prod, without having to do a lot of work.

Posted by Jeff Haynes on July 26, 2009 at 04:54 PM CEST #

@Jeff,

its actually my opinion - it works pretty well in the practice. And: Java EE improved significantly the productivity as well...

thanks!,

Posted by Adam Bien on July 26, 2009 at 05:37 PM CEST #

Hi Adam,

thanks for the clear words on this :) If I read you promoting Glassfish all the time, I was wondering, what your fav appserver solution for the future would be facing the Sun/Oracle merger..

Rgds
Markus

Posted by Markus on July 27, 2009 at 08:26 AM CEST #

@Markus,

I do not promoting Glassfish - I evaluated it several times and it seemed to be the best solution for our purposes. In the past I used JBoss almost exclusively, but the development stagnated a bit between the V4 and V5 and GF was the perfect replacement for JBoss. We should observe Geronimo as well - really interesting stuff is going now.
Btw. no-one really knows what happens after the Sun/Oracle merge. Perhaps GF will become the strategic choice for free? :-)

regards,

Posted by Adam Bien on July 27, 2009 at 10:38 AM CEST #

Adam,
Thanks for this post ! i bookmarked it for future reference.
for novice beginners, what do you advice them to start Java EE development ?
I'm ASP.NET programmer who's starving to start JEE development !

Posted by Amr on July 28, 2009 at 04:58 AM CEST #

@Amr,

it is actually very easy to start (watch some of my upcoming posts). The video in the right upper corner might be helpful for you. I created a whole Java EE application in about one hour.

I wrote several posts with the title "simplest possible": http://www.google.com/search?client=safari&rls=en-us&q=site:adam-bien.com+simplest+possible&ie=UTF-8&oe=UTF-8

They might be helpful for you as well,

thanks for your interests. And welcome to the exciting Java world :-).

Posted by Adam Bien on July 28, 2009 at 01:27 PM CEST #