Java News from Wednesday, October 20, 2004

Tom Copeland has released PMD 2.0, an open source tool for automatically checking Java code for various classes of bugs. PMD scans Java source code and looks for potential problems including:

This release adds a new logging ruleset It can also read the source code from zip and jar files, and the the HTML report include links to online source code. Most importantly, it now recognizes "NOPMD" comments in the code to indicate that it should not flag a particular violation of one of its rules, a feature that lint had 20 years ago and most Java static code checking tools have been sorely lacking until now. It may finally be possible to write 100% PMD-clean code.

As is my custom, I'm testing this by running it several code bases I have handy. I'm not expecting much because I do this with almost every release of every static code testing tool. The new logging rules didn't find anything, but I wouldn't expect them to since none of my code does any serious logging.

The basic rules found one minor problem (an extra semicolon) and one meidum serious problem (a do-nothing else block) amidst 127 false positives, mostly involving empty if blocks and catch statements. Possibly some of those should not be empty, but since so many of them should be it's hard to tell. In a lot of the cases, I could perhaps replace the empty blocks with continue statements.

The naming rules were flat out wrong, suggesting XOM shouldn't be using such "long" variable names as additionalPrefix, currentEntity, and baseAttribute. Let's lay this shibboleth to rest once and for all: cryptic variable names like addPrfx, cEnty, and baseAtt are a relic of 1970s era computers that had 32KB of memory and were lucky to be able to calculate the first 100 prime numbers without keeling over in exhaustion. Consequently languages designed for these pea-brained dinosaurs only considered the first eight characters of a name to be significant with led to the insane abbreviations that persist in C++ and Unix to this day. But this hasn't been an issue for at least 20 years. In 2004, there is no excuse for not using names long enough to convey the intent of the variable or method. On the flip side, PMS also complains about variables with "short names like in", a perfectly reasonable name for a variable of type InputStream.

Unused code detection is a strength of most such tools, and indeed PMD did find several more unused variables and statements that I could eliminate, even though I had run the previous version of this tool not long ago, and set Eclipse to flag unused code as an error. None of these were major, and about half could be classified as false positives, but all the real hits were easy fixes.

The Cyclomatic complexity detector did flag a few methods that I know are complex. However it also tended to incorrectly calculate the cyclomatic complexity for switch statements implemented via table lookup. In these cases the entire switch statement should count as a single decision point rather than one for each case. This sent some of my scores through the roof.

Cenqua has posted FishEye 0.5, a $999 payware tool for drawing graphs of CVS activity.


Robert Oloffson has posted version 0.44 of Java Memory Profiler (JMP). JMP uses the Java Virtual Machine Profiling Interface (JVMPI) interface to track objects and method times in a JVM. It uses a GTK+ interface to display statistics. The current instance count and the total amount of memory for each class is shown as is the total time spent in each method. 0.44 is mostly a bug fix release but also adds an "alloced/call" column to the method list. JMP is written in C for Linux.