Mike Clark

While adding some new entries to the JUnit FAQ this morning, I was once again reminded of Java's Achilles Heel - the onerous classpath.

JUnit newbies consistently have trouble correctly setting their CLASSPATH variable. And yet JUnit presents a relatively mild case of classpathitis. All you need is one jar file (junit.jar), your class files, and any other class files your class files depend on. Simple, right? Well, not if the number of mailing list questions regarding the classpath is any indication. The FAQ has helped reduce a lot of confusion, but the scourge of the classpath continues to be widespread throughout the Java community.

I've certainly been bitten by classpath problems more than once. The kind that result in a ClassNotFoundException are usually fairly easy to fix. It typically means your CLASSPATH variable doesn't have all the stuff it should. But the kind of classpath problems that don't conveniently throw exceptions are really nasty. You only suspect there's a problem because the version of a class you think is being used is not. It usually turns out that the class you're expecting to be used is masked by another version of the class at a higher precedence in the CLASSPATH variable. Those kind have a way of robbing massive amounts of your time.

A couple years ago I finally got tired of doing battle with the classpath. After all, it's just like the PATH variable, and the Unix which utility was created as a weapon against pathing problems. Fueled by frustration, I created JWhich to help hunt down insidious classpath problems. After using it to my advantage in a few battles, I wrote an article explaining how it's made my life with Java easier. I generally use it on the command line to check the system classpath, though some folks have adapted it for life inside of a servlet/EJB container. To address classpath problems specifically related to JUnit, WhichJUnit was born.

Perhaps these simple tools will help you spend more time doing the things you'd rather be doing.