Tom Copeland has released PMD 2.2, 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:
New rules in this release include LocalVariableCouldBeFinal, MethodArgumentCouldBeFinal, AvoidInstantiatingObjectsInLoops, ArrayIsStoredDirectly, MethodReturnsInternalArray, AssignmentToNonFinalStatic, and AvoidConcatenatingNonLiteralsInStringBuffer. This release also adds vbhtml output, whatever that is.
I remain amazed at how useful these tools are. I keep using them, and they keep finding more bugs. I just ran one ruleset (unused code) on XOM, and it found a whole pack of unused private fields, unused local variables, and unused private methods that have either been introduced or stopped being used since I last ran PMD a month or two ago. (It also reported a dozen or so false positives: methods that it claimed weren't used but actually were used, so there may be a few bugs introduced since 2.1.)
One thing PMD found a lot of was places where private fields, method arguments, and local variables could be declared final. The latter two are listed as optimization rules. I can believe that marking these as final wouldn't hurt, but would it really help? Shouldn't compilers be smart enough to figure out that the variable is effectively final, even if not marked so? I've always treated final on method arguments and local variables, as just a hint to the programmer. (Occasionally they are necessary to make anonymous inner classes work; very occasionally in my code, since I almost never use anonymous inner classes.) Could it actually speed up a program to explicitly mark these as final? Does the finality of local variables and method arguments actually appear in the byte code somehow where the JIT can take advantage of it, or is it compiled away? Suggestions appreciated.