First off, a caveat. I'm not some wet-behind-the-ears newbie who longs for Visual Basic. I've been coding in Java for over 5 years and have written 2 books on JSP development (MySQL & JSP Web Applications and Struts Kick Start, both from SAMS, run out and buy them right now). I'm a committer on the Jakarta Struts project. So I think I can claim I know my way around a polymorphism or two.

So when I say that Java developers seem to be in love with unneeded and confusing layers of complexity, I'm not say it from a position of ignorance. I'm saying it because I find myself frequently finding the Java way of doing something about 10 times as difficult as in other languages.

For example, I recently needed to automate encrypting and transmitting some files via FTP. Since I was already generating the plaintext file in Java, I figured it would be easy enough to tack on PGP and then send it. In fact, I already knew how to send it because I had other Java programs that did FTP. So all I needed to do was find a native Java PGP implementation, and sure enough, the Bouncy Castle folks had a native Java implementation free for the downloading.

Immediately, I ran into the thing I hate most about Java developers. They (as a group) are in love with how clever they can be. The Bouncy Castle code was a morass of Factories, multiple different classes that needed to be configured in order to make everything work right, and even at that I couldn't get it to work after a day of messing around. The mantra in Java seems to be to never hardwire anything, so that in the hypothetical "someday", you can rip out class X and put in class Y by just adding a Factory. The end result however, is code that's confusing to use, hard to maintain, and never seems to be very well documented.

In desperation, I turned to option 2, doing it in Perl. What a difference! One CPAN install got me the entire suite of packages I needed to make the Crypto::OpenPGP package work (and BOY could the Java community take a lesson from the success and good design of CPAN) The package was straightforward to use, maybe not the most elegant, infinitely extensable design possible, but easy to get up and working in 10 minutes.

I moderated a panel at COMDEX last fall where Rasmus Lerdorf (Mr. PHP) and a Perl proponent ganged up on the person representing Java, complaining about how slow it was and hard to develop in. I tried my best to help defend Java, but it was hard. The trouble is, I see their point.

Java is a great language. But for some reason, the Java community has decided to take it and make all the ancillary packages as complex and difficult to use as possible. It's like a racehorse that's had a wet bar and a hot tub mounted on it. The Perl folks have the right idea. Make supporting technologies that are simple to use, rather than so elegant that they become incomprehensible.

Imagine if the Perl cafe and Javahut were across the street from each other. You walk into Javahut, and ask to sit down. "I'm sorry," says the person at the door. I'm not actually the hostess, I'm a Factory class that can give you a hostess if you tell me what type of seat you want." You say you want a non-smoking seat, and the person calls over a NonSmokingSeatHostess. The hostess takes you to your seat, and asks if you'll want breakfast, lunch, or dinner. You say lunch, and she beckons a LunchWaitress. The LunchWaitress takes your order, brings over your food, but there's no plates to put it on because you forgot to get a CutleryFactory and invoke getPlates, so the Waitress throws a null pointer exception and you get thrown out of the place.

Dusting yourself off, you walk across the street to the Perl cafe. The person at the door asks what kind of seat you want, what you want to eat, and how you want to pay. They sit you at your seat, bring over your food, collect the money, and leave you to eat in peace. Sure, it's not the most elegant dining experience you ever had, but you got your food with a minimum of pain.

The long and the short of it is that, in my opinion, Java is a great language being destroyed by Rampaging Computer Science. There's a time for elegance, and a time for usability. If developers want to make the internals of packages flexible and extensible, that's all well and good. But the external interfaces should be clean, simple to use, and have wrappers for the most commonly accessed functionality. For example, in a PGP package, I should be able to encrypt or decrypt a file in 5 lines of code or less. After all, I can do it in Perl in 3.

• TURNER'S VIEWPOINT: The Emperor's New Clothes