Future Directions


This roadmap contains all the different 'workshops' PMD's developers are working right now.

  • TypeResolution Framework: A framework to ease type resolution of a variable in both XPath and Java Rules.
  • pmd-jerry: An XPath2 engine for PMD.
  • Migration to Maven 2: Hardly a user-feature but worth mentioning here.
  • French version of this website
  • Better symbol analysis: See below.
  • Data Flow Analysis: See below.
  • Code Cleanups: See below.
Please note that, of course, there is no warranty about when those 'features' will be finished, if they ever are.

Better symbol analysis

Currently PMD only looks at one source file at a time. Instead, it should resolve symbols across classes. This will eliminate some open bugs and enable a lot more rules to be written. However, it'll taken some doing, because it'll require parsing of class files. Lots of work here.

Data flow analysis (DFA)

Raik Schroeder, a graduate student at Fachhochschule Stralsund, has written a DFA layer that should enable us to write some more complicated rules - stuff like common subexpression elimination, loop invariant code motion (and code hoisting suggestions), shrink wrapping, and partial redundancy elimination. The code is currently in CVS in the net.sourceforge.pmd.dfa packages, and we're going through it now figuring out what rules we can write that use it. We should be able to use it to simplify some current rules, as well.

Code cleanups

Some of the code is a bit sloppy:

  • RuleSetFactory is a mess. It needs to be refactored into something that has layers, or decorators, or something.
  • Cleanups would be welcome for ConstructorCallsOverridableMethod and DoubleCheckedLocking
  • The Designer GUI is a bit messed up; the bottom panes look funny.
  • The grammar has some odd bits:
    • BlockStatement has an odd hack for class definitions inside methods
    • enumLookahead() seems like a bit of overkill, can it use Modifiers somehow?
    • The whole "discardable node" thing seems wasteful
    • Does ExtendsList need that 'extendsMoreThanOne' thing?
    • ClassOrInterfaceBodyDeclaration has a monstrous lookahead to check for enums
    • ClassOrInterfaceType gloms together dotted names... is that the right thing to do?
    • Some complicated annotations are currently broken