Tuesday, May 13, 2008

Things I Hate About You #2: Java

So - Java. Most of the folks who hadn't worked in Java would mumble something about speed or lack of native compilation when asked what they disliked. Now, I'm just coming back into Java development after being away since about 2000, but from what I've seen so far, these items still haven't improved much...
  1. TMTOWTDI (poorly) - The Perl motto is "There's more than one way to do it", and it (mostly) works well in Perl. You've got several ways to do something, and can choose the appropriate one for the task you're dealing with. Java, on the other hand, has far, far too many cases where they implemented one way to do something, realized it was wrong, implemented a second while leaving the first one in place. They can't just remove the first one, because it's embedded in other parts of the API, so it just...festers. The worst example of this is java.util.Date, which has 6 constructors (4 of which are deprecated) and 27 methods (17 of which are deprecated)...you can't just use Calendar everywhere, so you have to change back and forth between Date and Calendar all the time. In particular, if you're using SQL, java.sql.Date and its kin are all subclasses of Date, but you can't get any information out without using a deprecated call or converting it to a Calendar. (So what's the solution? JodaTime, of course! Replacing a broken API with another incompatible one is the Java Way!) Other examples: there are three separate UI systems now (Java 1.0.2 AWT, Java 1.1+ AWT, and Swing), there's the whole Reader/Writer vs. InputStream/OutputStream issue (now with Channels to make life even more confusing), HashTable/Vector vs. Collections...and those are just the ones off the top of my head. The biggest advantage that C# has is that Microsoft was able to learn from Sun's mistakes and not have as much deprecated cruft cluttering their APIs.
  2. Make the simple things simple and the hard things tedious - A pattern I've run into several times in Java: "To make this work, you need all these other objects to be in place...a convenience method is provided for the common case." And so, as long as you're doing exactly what the programmers expected, it's easy...and as soon as you wander even a little bit off that track, you need to do everything manually. Places I've run into this include Swing (JTable, specifically, as I recall) and security/cryptography (adding a new trusted key for an SSL connection).
  3. Frameworks upon Frameworks - Java EE is, apparently, built around the idea that if you have enough frameworks, every problem will come out of them eventually. Er, no, it's build around the idea that the solution to every problem will come out eventually. (In practice, it seems the first statement was more accurate, though.) Why I Hate Frameworks sums this up better than I can, though, so I'll let them have it. True story: I went to look into how to use a particular framework at work. Lo and behold, this framework in and of itself is an agglomeration of seven external frameworks plus four more internal frameworks. Now that's Enterprise.
I'd be interested to hear what other Java developers would choose for their three items.

No comments: