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
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
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 - firstname.lastname@example.org