Java's Achilles Heel.

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.

[Mike Clark]

CLASSPATH (and classloaders) may be too good a tool that is only good for high end stuff - like translation isolation inside VM - but bad for most simple usage like well loading up POJO.

(Embarrassingly only a few nights ago I was futzing around with java -classpath longpath Foo only to find Foo should've been full.package.name.Foo but the documentation of JPDA was wrong or rather it had typos.)

11:23:35 AM  #  

Quick update on decision about java build tools (or better name would be process/project management tool?) Anthill and cruisecontrol are more like build automation tools whereas maven and centipede cover lot more ground in project management area.

So far it looks like

anthill > cruisecontrol
maven > centipede

Anthill's web gui makes using and training new users easier. Also it has "forced build" feature. ALso it's darn easy to install - I just dropped its war to JRun and presto, it's running. CC's install was more involved judging from its documentation so I didn't bother.

Maven has better doc and organization. Both maven and centipede seem to have preconceptions about what a project is and how it should be organized -- customizing them would take work. Also both have many many xml config files to fiddle with. Not a good sign.

Question is: for simple, lightweight processes is it better to build a process management tool bottom up from anthill or top down by customizing either maven or centipede?

10:37:09 AM  #