Java support

Overview of supported Java language versions

Usually the latest non-preview Java Version is the default version.

Using Java preview features

In order to analyze a project with PMD that uses preview language features, you’ll need to enable it via the environment variable PMD_JAVA_OPTS and select the new language version, e.g. 22-preview:

export PMD_JAVA_OPTS=--enable-preview
pmd check --use-version java-22-preview ...

Note: we only support preview language features for the latest two java versions.

Language Properties

See Java language properties

Type and symbol resolution

Java being a statically typed language, a Java program contains more information than just its syntax tree; for instance, every expression has a static type, and every method call is bound to a method overload statically (even if that overload is virtual). In PMD, much of this information is resolved from the AST by additional passes, which run after parsing, and before rules can inspect the tree.

The semantic analysis roughly works like so:

1. The first passes resolve symbols, which are a model of the named entities that Java programs declare, like classes, methods, and variables.
2. Then, each name in the tree is resolved to a symbol, according to the language’s scoping rules. This may modify the tree to remove ambiguous names (names which could be either a type, package, or variable).
3. The last pass resolves the types of expressions, which performs overload resolution on method calls, and type inference.

The analyzed code might reference types from other places of the project or even from external dependencies. If e.g. the code extends a class from an external dependency, then PMD needs to know this external dependency in order to figure out, that a method is actually an override.

In order to resolve such types, a complete so-called auxiliary classpath need to be provided. Technically, PMD uses the ASM framework to read the bytecode and build up its own representation to resolve names and types. It also reads the bytecode of the Java runtime in order to resolve Java API references.

Providing the auxiliary classpath

The auxiliary classpath (or short “auxClasspath”) is configured via the Language Property “auxClasspath”. It is a string containing multiple paths separated by either a colon (:) under Linux/MacOS or a semicolon (;) under Windows. This property can be provided on the CLI with parameter --aux-classpath.

In order to resolve the types of the Java API correctly, the Java Runtime must be on the auxClasspath as well. As the Java API and Runtime evolves from version to version, it is important to use the correct Java version, that is being analyzed. This might not necessarily be the same Java runtime version that is being used to run PMD.

Until Java 8, there exists the jar file rt.jar in ${JAVA_HOME}/jre/lib. It is enough, to include this jar file in the auxClasspath. Usually, you would add this as the first entry in the auxClasspath.

Beginning with Java 9, the Java platform has been modularized and Modular Run-Time Images have been introduced. The file ${JAVA_HOME}/lib/modules contains now all the classes, but it is not a jar file anymore. However, each Java installation provides an implementation to read such Run-Time Images in ${JAVA_HOME}/lib/jrt-fs.jar. This is an implementation of the jrt:// filesystem and through this, the bytecode of the Java runtime classes can be loaded. In order to use this with PMD, the file ${JAVA_HOME}/lib/jrt-fs.jar needs to be added to the auxClasspath as the first entry. PMD will make sure, to load the Java runtime classes using the jrt-filesystem.

If neither ${JAVA_HOME}/jre/lib/rt.jar nor ${JAVA_HOME}/lib/jrt-fs.jar is added to the auxClasspath, PMD falls back to load the Java runtime classes from the current runtime, that is the runtime that was used to execute PMD. This might not be the correct version, e.g. you might run PMD with Java 8, but analyze code written for Java 21. In that case, you have to provide “jrt-fs.jar” on the auxClasspath.

Not providing the correct auxClasspath might result in false positives or negatives for some rules, such as MissingOverride. This rule needs to figure out, whether a method is defined already in the super class or interface. E.g. the method Collection#toArray(IntFunction) has been added in Java 11, and it does not exist yet in Java 8. Given a simple subclass of ArrayList, that overrides this method without adding @Override, then PMD won’t be able to detect this missing override annotation, if it is executed with a Java 8 runtime but without the correct auxClasspath. Providing the correct jrt-fs.jar from Java 11 (or later) for the auxClasspath allows PMD to correctly identify the missing annotation.

Example command line:

pmd check -d src/main/java \
  --aux-classpath=path/to/java17/lib/jrt-fs.jar:target/classes/ \
  -f xml -r pmd-report.xml -R rulesets/java/quickstart.xml

Symbol table APIs

Symbol table API related classes are in the package net.sourceforge.pmd.lang.java.symbols. The root interface for symbols is JElementSymbol.

The symbol table can be requested on any node with the method getSymbolTable. This returns a JSymbolTable which gives you access to variables, methods and types that are within scope.

A ASTExpression might represent a ASTAssignableExpr.ASTNamedReferenceExpr if it e.g. references a variable name. In that case, you can access the referenced variable symbol with the method getReferencedSym.

Declaration nodes, such as ASTVariableId implement the interface SymbolDeclaratorNode. Through the method getSymbol you can also access the symbol.

To find usages, you can call getLocalUsages.

Type resolution APIs

Type resolution API related classes are in the package net.sourceforge.pmd.lang.java.types.

The core of the framework is a set of interfaces to represent types. The root interface is JTypeMirror. Type mirrors are created by a TypeSystem object. This object is analysis-global.

The utility class TypeTestUtil provides simple methods to check types, e.g. TypeTestUtil.isA(String.class, variableDeclaratorIdNode) tests, whether the given variableDeclaratorId is of type “String”.

Any TypeNode provides access to the type with the method getTypeMirror. E.g. this can be called on ASTMethodCall to retrieve the return type of the called method.

Metrics framework

In order to use code metrics in Java, use the metrics constants in JavaMetrics, together with MetricsUtil. For instance:

@Override
public Object visit(ASTMethodDeclaration node, Object data) {
    if (JavaMetrics.NCSS.supports(node)) {
        int methodSize = MetricsUtil.computeMetric(JavaMetrics.NCSS, node, ncssOptions);
        if (methodSize >= level) {
            addViolation(data, node);
        }
    }
    return null;
}

The Javadocs are the reference documentation.

Violation Decorators

Violations reported are the same for all languages, but languages can opt in to provide more details. Java does this by adding the following additional information for each reported violation:

• VARIABLE_NAME
• METHOD_NAME
• CLASS_NAME
• PACKAGE_NAME

You can access these via getAdditionalInfo

Dataflow

There is no API yet for dataflow analysis. However, some rules such as UnusedAssignment or ImmutableField are using an internal implementation of an additional AST pass that adds dataflow information. The implementation can be found in net.sourceforge.pmd.lang.java.rule.internal.DataflowPass.