# Java support

Java-specific features and guidance
Table of Contents
Language Info for Java

- Since PMD 1.0.0
- Implementation: `JavaLanguageModule`
- Id: java
- PMD: ✔️
- CPD: ✔️

## Overview of supported Java language versions

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

Java Version | Alias | Supported by PMD since
--- | --- | ---
26-preview |  | 7.21.0
26 (default) |  | 7.21.0
25-preview |  | 7.16.0
25 |  | 7.16.0
24 |  | 7.10.0
23 |  | 7.5.0
22 |  | 7.0.0
21 |  | 7.0.0
20 |  | 6.55.0
19 |  | 6.48.0
18 |  | 6.44.0
17 |  | 6.37.0
16 |  | 6.32.0
15 |  | 6.27.0
14 |  | 6.22.0
13 |  | 6.18.0
12 |  | 6.13.0
11 |  | 6.6.0
10 | 1.10 | 6.4.0
9 | 1.9 | 6.0.0
8 | 1.8 | 5.1.0
7 | 1.7 | 5.0.0
6 | 1.6 | 3.9
5 | 1.5 | 3.0
1.4 |  | 1.2.2
1.3 |  | 1.0.0

## Using Java preview features

In order to analyze a project with PMD that uses preview language features, you’ll need to select the new language version, e.g. `26-preview`:

    pmd check --use-version java-26-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.

Tags: languages PmdCapableLanguage CpdCapableLanguage