I’ve been saying for years “The only time I program in Java is when someone pays me.” I was half joking, just stupid office banter, but I’m getting more and more sure about that opinion. Rant mode – engage. I spent the entire day today chasing down Java configuration errors when upgrading Resin 2 to Resin 3. It is a moderately complex application I’m upgrading. Built on Java 1.4, Spring, Hibernate, and JSTL, it really shouldn’t be that hard to upgrade. After hours of careful debugging, I found that it is a bad combination of JSTL and newly strict adherence to the JSTL spec that is causing most of my upgrade woes. Basically, Resin will no longer allow me to access a public static method of a class using Javabeans syntax conventions. Why? Because it is static. Not because it isn’t useful, but for the sake of strict interpretation of “the rules”. I seriously hate that attitude, which is very prevalent in the Java world. So, I need to rewrite many of my classes to make non-static class methods to access the same information I used to be able to get at directly. It leaves a bitter taste in my mouth.
Don’t trust the programmer
But that sort of “don’t trust the programmer” attitude is depressingly common in Java. Most everything is “strictly typed”, sure, but to work with a collection you always have to cast the object back to the proper type. Isn’t that “secret scary knowledge the programmer shouldn’t have to know”? I submit that it is. Doesn’t that break the supposedly big advantage of finding errors at compile time? Yes, it does. Can a good programmer get every bit of the same advantage and early error-validation by doing proper unit checks? Of course he can. So why do it like that, why be so wordy and needlessly strict? Because that’s Java’s corporate, designed by committee, not for love, spirit.
There are a lot of people debating the merits of the so-called “XML sit-ups” that many frameworks require. Java invented the XML sit-up. Spring is a gorgeous framework. It almost rescues Java in my eyes, but looking at the horrible horrible config files it requires almost brings junior programmers to tears. Seriously, take a look at the Spring Acegi security framework configuration files. I think that may be one of the most complex, interleaved, multi-layered config files I’ve ever seen. I strongly believe that that particular XML serves absolutely no purpose, and would actually be clearer, cleaner, and more testable if it was instead expressed in code. It saddens me to see Zope 3 heading down that same XML path. It is a myth that anyone other than a programmer will ever really be editing the config files. Why add needless cruft, delays and obfuscation? I don’t buy the “then it can be validated using XML validators” argument for one second. That’s like smashing an ant with a hammer.
Ugly Ugly JSTL
JSTL is another bitter pill. It is just unforgivably wordy. It is so amazingly wordy, and yet it fails to even remain valid XML. What the hell? I can forgive Zope Page Templates which are very wordy and involved, yet manage to remain valid XML the whole time. I still don’t really like them, but at least I can understand why some people do. JSP/JSTL on the other hand is so crufty, so layered and whacky, so inelegant, that it feels like the wrong solution every time. The programming community should simply throw it out and take a look at a decent, mature, truly object oriented solution like Cheetah for a well designed, terse and effective templating system. Why continue adding to the ugly pain that is JSP/JSTL? I have to think it is simple NIH syndrome at this point.
Conclusion, anyone having fun?
What I honestly find myself wondering is whether anyone actually programs in Java for fun. Or do they all do as I do, program in Java on the day job, come home, strip off the straightjacket, and dive into Python, Ruby or PHP? I hope so, for their sake. Java is a language with a broken spirit, and without exposure to other languages, I fear that Java developers will have their spirits crippled as surely as if they were VB developers.