Why J2EE sucks.

A lot of the problems with J2EE have to do with that first E. It stands for Enterprise. I assume we are to infer that it means it's scalable and can handle an obscene amount of usage. My experience has shown me otherwise.

Java's design philosophy is fundamentally flawed in that it conflicts with itself, strong typing AND sloppy garbage collection. One infers that the programmer is supposed to be aware of what his programs are doing, down to the letter, and the other allows him to make objects willy nilly and not worry about cleanup of memory, and since garbage collection is random, you have no ability to control critical performance sections of your program, to keep them from being interrupted by the garbage collector. Perhaps this has been addressed, but certainly if it has, it's a hack.

It is impossible to have the same message driven bean bind to multiple queue listeners. You must make numerous beans, one for each listener. There's no inherent way to scale message beans if you have any requirement of maintaining processing order of items off a queue. Not very Enterprise, if you ask me. A sea of beans makes for a universe of sloppiness that you can't organize or archive away somewhere.

Because the J2EE universe isn't modeled after reality, dealing with reality-tools (CVS for example) is sloppy because nothing else really relates to the paradigm.

Despite the fact that we've been building complex systems for well over 20 years, the idea of planning a build process for Enterprise applications has escaped our J2EE design friends. Ant is the hack designed to address this (yet another) not thought out problem. Make works nicely for the rest of us. “Form over function” they said. J2EE sure looks nice on a powerpoint presentation though, doesn't it.

Performance Performance Performance. (The lack thereof.) Be it local function calls, or using java in the first place, the Enterprise solution for performance is to inhibit it as much as possible.

Buzzword compliance is apparently a major design goal.

There are no less than FOUR layers of abstraction between your program and a queue implementation. How many times have you ever been able to just 'plug in' a new database or messaging service without a major porting effort? It just doesn't work that way.

Portability. How many times have you abandoned support your customer's hardware and switched to a new platform, but thank god, you wrote your applications in java, so they're portable, and will run on any hardware.

RE: Java: p-code didn't work in the 70's I don't see any reason it should now.

Local references are a hack when it was realized that most calls don't need to be remote, and a lot of overhead is caused by all that remoteness on a local machine. And even the local reference interface is still not as simple as a function call. At least 3 to 4 functions are called to call a local function in another bean.

One word: XML.

All this complicated abstraction separating the application from resources like databases works great for the positive test case. But what about when things go wrong? The application has no control over restablishing database connections after a network failure because the container and connection pooler is going to do it for you. And who tells the connection pooler not to open 1000 database connections at the same time? Oh that's right, you're talking about a big system. J2EE doesn't support that.

To say that IBM Websphere (studio and application server) sucks isn't necessarily a degrading comment. In fact, it's a complement. In order to arrive at a good implementation of J2EE, your software must suck. If Websphere ran with any measure of reasonable performance or ease of use, it would by definition be a failure of an implementation of J2EE.

I'll add more as I come across problems.

Stu - spamme@deadpelican.com