May 2006 Archives

In a recent discussion on the Magnolia developers list, Nicolas referred to a post discussing the negative side-effects of using JDK 1.5 to code readability. This pretty well demonstrates one of the reasons Java bugs: the developers want a language that guarantees code readability.

I'm all for code readability, but Java programmers seem to have an irrational fear of giving out tools that could be used for evil. This is a pretty irrational fear since Java already has features like the reflection API, which is like a programmer's version of the nuclear option, one mistep and you've blown up half the planet and it makes some of the worst code I've ever seen.

Anyway, David Flanagan points out that the new import static can make your code less readable. He contrives a couple examples of poor uses of the new construct and warns folks. Now, I want to say that Flanagan has it correct, "This isn't meant as criticism of static import; just an exploration of it." My criticism is of Nicolas and others that make statements like, "I would tend to think it's better to stay with 1.4, especially as the code is easier to read. (in my own opinion). [sic]" JDK 1.5 is not any less readable than JDK 1.4. That's like saying British English is less readable than American English, it's not a valid comparison. It's the usage that matters.

If someone engages in irresponsible coding via the static import mechanism, is this any worse than some of the issues one can have with regular imports? For example, look at:

import com.boomer.mgnl.firmadmin.User;

// Later...

public info.magnolia.mgnl.user.external.bean.User copyToExternalUser(User firmUser) {

  info.magnolia.user.external.bean.User user = new info.magnolia.user.external.bean.User();

  user.setFirstName(firmUser.getFirstName());

  return user;

}

I have some of that crap in my code because User was used to name an interface in one package, a bean implementation in another, and an extension of that bean in another, and then used in a totally different module to connect to external users in another place. This is an example of poor choice in names. If your application is going to have multiple user classes that might be used in the same object now or in the future, name them something different from each other! The code above works in JDK 1.4, so JDK 1.4 code can also be hard to read.

Thus, the point for any programmer in any language, is think when you write your code. You can write horrible code in even the simplest language with the best enforced rules and weakest capabilities. Adding powerful tools that can be abused does not mean that the code will suddenly become unreadable, it just means that you've got a few extra pitfalls that you need to put railings around (i.e., corporate/project policies to make sure no one does the stupid). And then, you have to have code reviews and enforce these policies on yourselves or via a community.

I hope that wasn't too much of a rant and I hope my ramble didn't negate what I said too much. Cheers.

I'm currently working on the last minute preparations for the launch of a new web site for Boomer.com. We are using a pretty decent piece of software for the side, called Magnolia. However, one issue in the Magnolia source that's been bugging me is the use of java.lang.Exception in many throws/catch clauses.

This is a pretty nasty habit that Java developers should avoid. Often when building code quickly or when you're making a lot of changes, it may be tempting to engage in this habit, but it's a fairly bad idea. Let me enumerate:

1. Catching Exception may catch errors you aren't really anticipating and handle them in ways thare aren't correct or mask them from appearing higher up in the call stack where they belong. For example, you may write a piece of coding expecting some kind of database errors that should be ignored, but you end up spending an hour ro two trying to track down a problem because something throws the infamous NPE, but you were ignoring it rather than coping with it, which led to some other problem in your code 500 lines later. Not cool.
2. Catching Exception involves treating all errors the same, which is rarely the right way to handle problems. Generally, each exception should be handled differently. For example, a database connection problem shouldn't be treated the same as a failure to return an expected result. On the web, the former might result in a 500 Internal Server Error and the latter might be better described as a 404 File Not Found error. Those are very different responses.
3. Catching Exception rather than the specific exceptions masks changes to code that will affect other parts of the code. For example, if I write a piece of code that throws errors that are generally ignored, but later come back and add another function call which adds a new exception that really needs to be handled by the caller in the 4 or 5 places the method is used, I might not catch all 4 or 5 places if my throws clause just contains Exception. This isn't smart use of the static checker to help me find places where a code change might propogate elsewhere.
4. Catching specific exceptions helps to make code self-documenting and easier to read. If all the code just catches Exception or states a throws clause of Exception, that's a really poor indicator of the kinds of errors one can expect from that method. If you also don't include any JavaDoc or wait until later to add your docs, it may take a lot of deep looking to find out what errors are really possible.

If you are a Java programmer, you should avoid this trap. No matter how tempting it is, even on code you plan to use just a few times and then throw away, you ought to think about this carefully. There've been far too many times in my programming experience where a little bit of temporary throw away code suddenly became permanent because I found it more useful than anticipated or project goals changed. I don't want to write some quickie code that I then have to go back and rewrite because I hacked it together with a bunch of bad habits, if I end up reusing it. I expect most programmers don't.

Anyway, don't code stupid. You don't want to be featured on The Daily WTF. Cheers.

I was interested in finding out what the latest changes were to the Maven2 plugin for Eclipse, so I hopped on over to take a look and, as most teeny OSS projects, there's no properly documented changelog, but it does have a source code repository. Most contain something almost as good. I ended up following the link to the VCS leading here, which suddenly dazzled my eyes with a very cool tool for viewing a source tree. They used a tool from Cenqua called fisheye.

Now, I'm not a big fan of the look and feel, but the features provided by are very nice. It includes graphs for monitoring code size. It includes annotations and version numbers per line when you view an individual file so you can note how old a particular set of changes is or who made them. One graph shows the number of lines currently selected text files have contained over the history of a project. The coolest chart I've seen so far is a chart showing branches and tags that have been made for a given file.

Just on first look, this tool looks pretty cool. They also have a pretty nice tour, where they show it off via Ant's repository.

Cheers.