While cleaning up the old laptop I ran across a series of Java/J2EE rants I’d written a couple of years ago that made me laugh. I must’ve been pretty pissed off when I wrote them, and I ended up never publishing them. They’re a bit dated, and I’m very happy to see that there’s been good progress on the non-J2EE, Python, and Ruby fronts. Here’s an excerpt for my own future amusement…
(The code-in-comments thing I was referencing was XDoclet, if I remember correctly)
…
Java has gone from an elegant, well thought out language to a twisted, nefarious movement that’s rapidly turning an entire generation of developers into acronym spouting, bloat producing, uninformed zombies.
What’s that saying about not grocery shopping when you’re hungry – there should be a corollary that you shouldn’t blog when you’re pissed off.
I like Java. The language itself is really quite nice and very usable. The various libraries it ships with are finally getting into decent shape. Java is delicious and refreshing.
Java, however, is no longer a programming language. It’s a movement. It encompasses a whole world of patterns, APIs, deployment models, all kinds of wonderful things.
In an imaginary world, far far away and long long ago, it used to be you could reasonably start a design with the simplest possible implementation. Can I write this in 10 lines of code and a couple of flat files? No? Damn. Ok, let me see if I can use a hash or dbm. No? Damn. I guess I’ll need a database. Is this thing going to take more than 10 lines? Damn. What’s the minimum I could write to make this thing work?
Because we were lazy and didn’t like writing code, we’d think of a clever solution that wouldn’t take a lot of lines. Because we were lazy, we never learned all the fancy nasty language specific tricks to make the code tricky; we just wrote the algorithm in basic constructs that an idiot off the street could understand. The intelligent part was the design, the algorithm, not the details of your code.
Then came along Java. Nice. A clean language, saved you from a lot of the headaches of C++, and made you feel better than writing Perl. The future was bright.
Then Java went to hell, flying high on the wings of that Satan known as J2EE. Patterns became popular. We started getting deployment descriptors in some XML dialect that was more complicated than the program we were deploying.
Today your basic hello world program is a couple of hundred lines of code. Today we’re writing 9 files to implement a single EJB. Mind you, the remote interfaces never actually get reused because our API design is a horrible piece of dung to begin with, and it’s hard enough to reuse well designed APIs, but at least our house made of straw is well decorated.
Ahah, you say, but I don’t have to be clever about designing my APIs: I’ve got patterns to follow. I don’t need to think, somebody already figured it out for me. I just have to pick the right pattern. Exactly….
But wait, you say, I have a solution to the 9 files to implement an EJB with lots of repeated code thing: I’ll use a code generator!. And you know what? I’ll do it by putting special code in comments in my Java files. Yes, code in comments. What do you mean? That’s a perfectly sane thing to do. After all, comments are not *really* comments. We’re already putting our documentation in there, so what’s a little bit of code? How’s that? Debugging the generated code? No, why would that be a problem? This is beyond 4GL, we’re like on 17GL. We don’t have bugs.
Now hold on, you say, this is Enterprise Java Beans. Not girly-man kiddie-toy Java Beans, we’re talking Enterprise. This is good solid stuff. Maybe I do have to suffer needlessly, use 3 levels of indirection and code generation instead of actually writing code, and require lots of heavy infrastructure to deploy the app, but at least I get transactions, stability, performance, scale, clustering, plus a few hundred acronyms. I can’t believe you’re still actually considering that ridiculous 10 lines of code and a flat file nonsense. I’m talking JMS baby. We’re Enterprise people here and we don’t play with kids’ toys anymore.
Excellent. Now you deploy your EJBs, and, big surprise, performance is horrendous. Shocking. How could it be? The 19 layers of indirection must make this thing go faster? No? Container managed something or another? I’m positive the next release of the App server or the alternate JDK will fix everything.
Now we go to production and things start breaking. I’ve got stuck threads? Impossible. How could I possibly have deadlock when my contention is managed 3 layers below what I’m actually coding? Must be the third layer of database abstraction. Are the deployment descriptors on that box ok? Where’s my JNDI server? Did you name the queue correctly? Increase the memory allocation; the garbage collector doesn’t kick in under that kind of load.
If you’ve been following our little story here, you’re probably thinking that I’ve gone off the deep end and stopped taking my medication. My friend, that happened long ago.
The reason I’m worked up is that I see unnecessary J2EE over and over, with disastrous results. But the reason I’m really upset is that the people designing these systems are smart, good people, and they’re genuinely convinced they’re right. They truly believe if they simply follow the right set of acronyms, they will arrive at a happy place.
It’s surprising really. We’re supposed to be skeptics. We’re technologists, we question everything. We hate marketing. Yet, as soon as we hit the J2EE marketing machine, we become sheep, too meek to question. It says Enterprise right there in the title. How can that be wrong? Somebody smart says it’s a good thing. I can get a job if I put it on my resume, you fool!
Just look around. Of the J2EE projects you have seen, how many are actually faster, more stable, or easier to maintain than if they had been implemented without J2EE?
My point? I’m sure I’ll make a point sometime, perhaps in the next episode of this rant. But for now, if you’re a Java guy, go learn Python. It won’t take you long. Go write something in it. Appreciate how much can be accomplished with a few strings and a couple of hashes (aka dictionaries). Simplify. Start with the solution that takes the least infrastructure. Forget the acronyms you know. Think in terms of algorithms, not programming languages.
Here’s a thought: the answer to single point of failure is not to create multiple points of failure.
Meanwhile, I’ve got to provision 3 times as many boxes to solve each problem and 19 separate things that could break to render my app useless. God forbid I should actually want audit trails…
You’re a young developer. You can learn J2EE and JMS, stick it on your resume, and pass a job checklist. Or, you can learn state machines, statistical methods, and classification. You can stick those on your resume too, but they won’t get you past a checklist. The recruiter will look at your resume, not see his favourite acronym, and move on.
So let’s see, learn acronyms and get a job, or learn real usable algorithms and techniques and get nothing….
You see the problem. What really gets my goat is that this insidious movement attacks the mind first. It convinces people that they’re doing the right thing, when in reality the simple answer is right there in front of them, if they just learn one or two real concepts instead of acronyms.
…