These are the detailed release notes for PMD 7.

🚀 Major Features and Enhancements

Many of you probably have already seen the new logo, but now it’s time to actually ship it. The new logo was long ago decided (see #1663).

We decided it’s time to have a modernized logo and get rid of the gun. This allows to include the logo anywhere without offense.

The official logo is also without a tagline (such as “Code Quality Matters!”) as the tagline created some controversies. Without a tagline, we are not limited in the direction of future development of PMD.

New PMD Logo

The new logo is available from the Logo Project Page.

Revamped Java

The Java grammar has been refactored substantially in order to make it easier to maintain and more correct regarding the Java Language Specification. It supports now also the edge-cases where PMD 6 was failing (e.g. annotations were not supported everywhere). Changing the grammar entails a changed AST and therefore changed rules. The PMD built-in rules have all been upgraded and many bugs have been fixed on the way. Unfortunately, if you are using custom rules, you will most probably need to accommodate these changes yourself.

The type resolution framework has been rewritten from scratch and should now cover the entire Java spec correctly. The same is true for the symbol table. PMD 6 on the other hand has always had problems with advanced type inference, e.g. with lambdas and call chains. Since it was built on the core reflection API, it also was prone to linkage errors and classloader leaks for instance. PMD 7 does not need to load classes, and does not have these problems.

The AST exposes much more semantic information now. For instance, you can jump from a method call to the declaration of the method being called, or from a field access to the field declaration. These improvements allow interesting rules to be written that need precise knowledge of the types in the program, for instance to detect UnnecessaryBoxing or UseDiamondOperator. These are just a small preview of the new rules we will be adding in the PMD 7 release cycle.

Overall, the changes to the parser, AST, type resolution and symbol table code has made PMD for Java significantly faster. On average, we have seen ~2-3X faster analysis, but as usual, this may change depending on your workload, configuration and ruleset.

Contributors: Clément Fournier (@oowekyala), Andreas Dangel (@adangel), Juan Martín Sotuyo Dodero (@jsotuyod)

Annotations

Annotations are consolidated into a single node. SingleMemberAnnotation, NormalAnnotation and MarkerAnnotation are removed in favour of ASTAnnotation. The Name node is removed, replaced by a ASTClassOrInterfaceType.

Those different node types implement a syntax-only distinction, that only makes semantically equivalent annotations have different possible representations. For example, @A and @A() are semantically equivalent, yet they were parsed as MarkerAnnotation resp. NormalAnnotation. Similarly, @A("") and @A(value="") were parsed as SingleMemberAnnotation resp. NormalAnnotation. This also makes parsing much simpler. The nested ClassOrInterface type is used to share the disambiguation logic.

Related issue: [java] Use single node for annotations (#2282)

Annotation AST Examples
CodeOld AST (PMD 6)New AST (PMD 7)
@A

+ Annotation
  + MarkerAnnotation
    + Name "A"

+ Annotation
  + ClassOrInterfaceType "A"

@A()

+ Annotation
  + NormalAnnotation
    + Name "A"

+ Annotation "A"
  + ClassOrInterfaceType "A"
  + AnnotationMemberList

@A(value="v")

+ Annotation
  + NormalAnnotation
    + Name "A"
    + MemberValuePairs
      + MemberValuePair "value"
        + MemberValue
          + PrimaryExpression
            + PrimaryPrefix
              + Literal '"v"'

+ Annotation "A"
  + ClassOrInterfaceType "A"
  + AnnotationMemberList
    + MemberValuePair "value" [@Shorthand=false()]
      + StringLiteral '"v"'

@A("v")

+ Annotation
  + SingleMemberAnnotation
    + Name "A"
    + MemberValue
      + PrimaryExpression
        + PrimaryPrefix
          + Literal '"v"'

+ Annotation "A"
  + ClassOrInterfaceType "A"
  + AnnotationMemberList
    + MemberValuePair "value" [@Shorthand=true()]
      + StringLiteral '"v"'

@A(value="v", on=true)

+ Annotation
  + NormalAnnotation
    + Name "A"
    + MemberValuePairs
      + MemberValuePair "value"
        + MemberValue
          + PrimaryExpression
            + PrimaryPrefix
              + Literal '"v"'
      + MemberValuePair "on"
        + MemberValue
          + PrimaryExpression
            + PrimaryPrefix
              + Literal
                + BooleanLiteral [@True=true()]

+ Annotation "A"
  + ClassOrInterfaceType "A"
  + AnnotationMemberList
    + MemberValuePair "value" [@Shorthand=false()]
      + StringLiteral '"v"'
    + MemberValuePair "on"
      + BooleanLiteral [@True=true()]

Types

  • ASTType and ASTReferenceType have been turned into interfaces, implemented by ASTPrimitiveType, ASTClassOrInterfaceType, and the new node ASTArrayType. This reduces the depth of the relevant subtrees, and allows to explore them more easily and consistently.

  • ASTClassOrInterfaceType appears to be left recursive now. TODO document that when we’re done discussing the semantic rewrite phase.

  • Migrating

    • There is currently no way to match abstract types (or interfaces) with XPath, so Type and ReferenceType name tests won’t match anything anymore.
    • Type/ReferenceType/ClassOrInterfaceType -> ClassOrInterfaceType
    • Type/PrimitiveType -> PrimitiveType.
    • Type/ReferenceType[@ArrayDepth>1]/ClassOrInterfaceType -> ArrayType/ClassOrInterfaceType.
    • Type/ReferenceType/PrimitiveType -> ArrayType/PrimitiveType.
    • Note that in most cases you should check the type of a variable with e.g. VariableDeclaratorId[pmd-java:typeIs("java.lang.String[]")] because it considers the additional dimensions on declarations like String foo[];. The Java equivalent is TypeHelper.isA(id, String[].class);

Declarations

TODO

Statements

TODO

Expressions

  • ASTExpression and ASTPrimaryExpression have been turned into interfaces. These added no information to the AST and increased its depth unnecessarily. All expressions implement the first interface. Both of those nodes can no more be found in ASTs.

  • Migrating:
    • Basically, Expression/X or Expression/PrimaryExpression/X, just becomes X
    • There is currently no way to match abstract or interface types with XPath, so Expression or PrimaryExpression name tests won’t match anything anymore. However, the axis step *[@Expression=true()] matches any expression.
  • ASTLiteral has been turned into an interface. The fact that ASTNullLiteral and ASTBooleanLiteral were nested within it but other literals types were all directly represented by it was inconsistent, and ultimately that level of nesting was unnecessary.
  • Migrating:
    • Remove all /Literal/ segments from your XPath expressions
    • If you tested several types of literals, you can e.g. do it like /*[self::StringLiteral or self::CharLiteral]/
    • As is usual, use the designer to explore the new AST structure
  • The nodes ASTPrimaryPrefix and ASTPrimarySuffix are removed from the grammar. Subtrees for primary expressions appear to be left-recursive now. For example,
new Foo().bar.foo(1)

used to be parsed as

Expression
+ PrimaryExpression
  + PrimaryPrefix
    + AllocationExpression
      + ClassOrInterfaceType[@Image="Foo"]
  + PrimarySuffix
    + Arguments
  + PrimarySuffix
    + Name[@Image="bar.foo"]
  + PrimarySuffix
    + Arguments
      + ArgumentsList
        + Expression
          + PrimaryExpression
            + Literal[@ValueAsInt=1]

It’s now parsed as

MethodCall[@MethodName="foo"]
+ FieldAccess[@FieldName="bar"]
  + ConstructorCall
    + ClassOrInterfaceType[@TypeImage="Foo"]
    + ArgumentsList
+ ArgumentsList
  + NumericLiteral[@ValueAsInt=1]

Instead of being flat, the subexpressions are now nested within one another. The nesting follows the naturally recursive structure of expressions:

new Foo().bar.foo(1)
---------            ConstructorCall
-------------        FieldAccess
-------------------- MethodCall

This makes the AST more regular and easier to navigate. Each node contains the other nodes that are relevant to it (e.g. arguments) instead of them being spread out over several siblings. The API of all nodes has been enriched with high-level accessors to query the AST in a semantic way, without bothering with the placement details.

The amount of changes in the grammar that this change entails is enormous, but hopefully firing up the designer to inspect the new structure should give you the information you need quickly.

TODO write a summary of changes in the javadoc of the package, will be more accessible.

Note: this doesn’t affect binary expressions like ASTAdditiveExpression. E.g. a+b+c is not parsed as

AdditiveExpression
+ AdditiveExpression
  + (a)
  + (b)
+ (c)

It’s still

AdditiveExpression
+ (a)
+ (b)
+ (c)

which is easier to navigate, especially from XPath.

Revamped Command Line Interface

PMD now ships with a unified Command Line Interface for both Linux/Unix and Windows. Instead of having a collection of scripts for the different utilities shipped with PMD, a single script pmd (pmd.bat for Windows) can now launch all utilities using subcommands, e.g. pmd check, pmd designer. All commands and options are thoroughly documented in the help, with full color support where available. Moreover, efforts were made to provide consistency in the usage of all PMD utilities.

$ Usage: pmd [-hV] [COMMAND]
  -h, --help      Show this help message and exit.
  -V, --version   Print version information and exit.
Commands:
  check     The PMD standard source code analyzer
  cpd       Copy/Paste Detector - find duplicate code
  designer  The PMD visual rule designer
  cpd-gui   GUI for the Copy/Paste Detector
              Warning: May not support the full CPD feature set
  ast-dump  Experimental: dumps the AST of parsing source code
Exit Codes:
  0   Succesful analysis, no violations found
  1   An unexpected error occurred during execution
  2   Usage error, please refer to the command help
  4   Successful analysis, at least 1 violation found

For instance, where you previously would have run

run.sh pmd -d src -R ruleset.xml

you should now use

pmd check -d src -R ruleset.xml

or even better, omit using -d / --dir and simply pass the sources at the end of the parameter list

pmd check -R ruleset.xml src

Multiple source directories can be passed, such as:

pmd check -R ruleset.xml src/main/java src/test/java

And the exact same applies to CPD:

pmd cpd --minimum-tokens 100 src/main/java

Additionally, the CLI for the check command has been enhanced with a progress bar, which interactively displays the current progress of the analysis.

Demo

This can be disabled with the --no-progress flag.

Finally, we now provide a completion script for Bash/Zsh to further help daily usage. This script can be found under shell/pmd-completion.sh in the binary distribution. To use it, edit your ~/.bashrc / ~/.zshrc file and add the following line:

source *path_to_pmd*/shell/pmd-completion.sh

Contributors: Juan MartĂ­n Sotuyo Dodero (@jsotuyod)

Full Antlr support

PMD 6 only supported JavaCC based grammars, but with Antlr parsers can be generated as well. Languages backed by an Antlr grammar are now fully supported. This means, it’s now possible not only to use Antlr grammars for CPD, but we can actually build full-fledged PMD rules for them as well. Both the traditional Java visitor rules, and the simpler XPath rules are available to users. This allows to leverage existing grammars.

We expect this to enable both our dev team and external contributors to largely extend PMD usage for more languages.

Two languages (Swift and Kotlin) already use this new possibility.

Contributors: Lucas Soncini (@lsoncini), Matías Fraga (@matifraga), Tomás De Lucca (@tomidelucca)

Updated PMD Designer

This PMD release ships a new version of the pmd-designer. For the changes, see PMD Designer Changelog.

🎉 Language Related Changes

New: Swift support

Given the full Antlr support, PMD now fully supports Swift. We are pleased to announce we are shipping a number of rules starting with PMD 7.

  • ForceCast (swift-errorprone) flags all force casts, making sure you are defensively considering all types. Having the application crash shouldn’t be an option.
  • ForceTry (swift-errorprone) flags all force tries, making sure you are defensively handling exceptions. Having the application crash shouldn’t be an option.
  • ProhibitedInterfaceBuilder (swift-bestpractices) flags any usage of interface builder. Interface builder files are prone to merge conflicts, and are impossible to code review, so larger teams usually try to avoid it or reduce its usage.
  • UnavailableFunction (swift-bestpractices) flags any function throwing a fatalError not marked as @available(*, unavailable) to ensure no calls are actually performed in the codebase.

Contributors: Lucas Soncini (@lsoncini), Matías Fraga (@matifraga), Tomás De Lucca (@tomidelucca)

New: Kotlin support (experimental)

PMD now supports Kotlin as an additional language for analyzing source code. It is based on the official kotlin Antlr grammar. Java-based rules and XPath-based rules are supported.

Kotlin support has experimental stability level, meaning no compatibility should be expected between even incremental releases. Any functionality can be added, removed or changed without warning.

We are shipping the following rules:

  • FunctionNameTooShort (kotlin-bestpractices) finds functions with a too short name.
  • OverrideBothEqualsAndHashcode (kotlin-errorprone) finds classes with only either equals or hashCode overridden, but not both. This leads to unexpected behavior once instances of such classes are used in collections (Lists, HashMaps, …).

Contributors: Jeroen Borgers (@jborgers), Peter Paul Bakker (@stokpop)

New: CPD support for TypeScript

Thanks to a contribution, CPD now supports the TypeScript language. It is shipped with the rest of the JavaScript support in the module pmd-javascript.

Contributors: Paul Guyot (@pguyot)

New: CPD support for Julia

Thanks to a contribution, CPD now supports the Julia language. It is shipped in the new module pmd-julia.

Contributors: Wener (@wener-tiobe)

Changed: JavaScript support

The JS specific parser options have been removed. The parser now always retains comments and uses version ES6. The language module registers a couple of different versions. The latest version, which supports ES6 and also some new constructs (see Rhino]), is the default. This should be fine for most use cases.

Changed: Language versions

We revisited the versions that were defined by each language module. Now many more versions are defined for each language. In general, you can expect that PMD can parse all these different versions. There might be situations where this fails and this can be considered a bug. Usually the latest version is selected as the default language version.

The language versions can be used to mark rules to be useful only for a specific language version via the minimumLanguageVersion and maximumLanguageVersion attributes. While this feature is currently only used by the Java module, listing all possible versions enables other languages as well to use this feature.

Related issue: [core] Explicitly name all language versions (#4120)

🌟 New and changed rules

New Rules

Apex

Java

  • UnnecessaryBoxing reports boxing and unboxing conversions that may be made implicit.

Kotlin

Swift

Changed Rules

General changes

Apex General changes

  • The properties cc_categories, cc_remediation_points_multiplier, cc_block_highlighting have been removed from all rules. These properties have been deprecated since PMD 6.13.0. See issue #1648 for more details.

Java General changes

  • Violations reported on methods or classes previously reported the line range of the entire method or class. With PMD 7.0.0, the reported location is now just the identifier of the method or class. This affects various rules, e.g. CognitiveComplexity.

    The report location is controlled by the overrides of the method getReportLocation in different node types.

    See issue #4439 and issue #730 for more details.

Java Best Practices

  • ArrayIsStoredDirectly: Violations are now reported on the assignment and not anymore on the formal parameter. The reported line numbers will probably move.
  • AvoidReassigningLoopVariables: This rule might not report anymore all reassignments of the control variable in for-loops when the property forReassign is set to skip. See issue #4500 for more details.
  • LooseCoupling: The rule has a new property to allow some types to be coupled to (allowedTypes).
  • UnusedLocalVariable: This rule has some important false-negatives fixed and finds many more cases now. For details see issues #2130, #4516, and #4517.

Java Codestyle

  • MethodNamingConventions: The property checkNativeMethods has been removed. The property was deprecated since PMD 6.3.0. Use the property nativePattern to control whether native methods should be considered or not.
  • ShortVariable: This rule now also reports short enum constant names.
  • UseDiamondOperator: The property java7Compatibility has been removed. The rule now handles Java 7 properly without a property.
  • UnnecessaryFullyQualifiedName: The rule has two new properties, to selectively disable reporting on static field and method qualifiers. The rule also has been improved to be more precise.
  • UselessParentheses: The rule has two new properties which control how strict the rule should be applied. With ignoreClarifying (default: true) parentheses that are strictly speaking not necessary are allowed, if they separate expressions of different precedence. The other property ignoreBalancing (default: true) is similar, in that it allows parentheses that help reading and understanding the expressions.

Java Design

  • CyclomaticComplexity: The property reportLevel has been removed. The property was deprecated since PMD 6.0.0. The report level can now be configured separated for classes and methods using classReportLevel and methodReportLevel instead.
  • ImmutableField: The property ignoredAnnotations has been removed. The property was deprecated since PMD 6.52.0.
  • LawOfDemeter: The rule has a new property trustRadius. This defines the maximum degree of trusted data. The default of 1 is the most restrictive.
  • NPathComplexity: The property minimum has been removed. It was deprecated since PMD 6.0.0. Use the property reportLevel instead.
  • SingularField: The properties checkInnerClasses and disallowNotAssignment have been removed. The rule is now more precise and will check these cases properly.
  • UseUtilityClass: The property ignoredAnnotations has been removed.

Java Documentation

  • CommentContent: The properties caseSensitive and disallowedTerms are removed. The new property forbiddenRegex can be used now to define the disallowed terms with a single regular expression.
  • CommentRequired:
    • Overridden methods are now detected even without the @Override annotation. This is relevant for the property methodWithOverrideCommentRequirement. See also pull request #3757.
    • Elements in annotation types are now detected as well. This might lead to an increased number of violations for missing public method comments.
  • CommentSize: When determining the line-length of a comment, the leading comment prefix markers (e.g. * or //) are ignored and don’t add up to the line-length. See also pull request #4369.

Java Error Prone

  • AvoidDuplicateLiterals: The property exceptionfile has been removed. The property was deprecated since PMD 6.10.0. Use the property exceptionList instead.
  • DontImportSun: sun.misc.Signal is not special-cased anymore.
  • EmptyCatchBlock: CloneNotSupportedException and InterruptedException are not special-cased anymore. Rename the exception parameter to ignored to ignore them.
  • ImplicitSwitchFallThrough: Violations are now reported on the case statements rather than on the switch statements. This is more accurate but might result in more violations now.

Deprecated Rules

In PMD 7.0.0, there are now deprecated rules.

Removed Rules

The following previously deprecated rules have been finally removed:

Apex

Java

đź’Ą Compatibility and Migration Notes

For endusers

  • PMD 7 requires Java 8 or above to execute.
  • CLI changed: Custom scripts need to be updated (run.sh pmd ... -> pmd check ..., run.sh cpd ..., pmd cpd ...).
  • Java module revamped: Custom rules need to be updated.
  • Removed rules: Custom rulesets need to be reviewed. See below for a list of new and removed rules.
  • XPath 1.0 support is removed, violationSuppressXPath now requires XPath 2.0 or 3.1: Custom rulesets need to be reviewed.
  • Custom rules using rulechains: Need to override buildTargetSelector using forTypes.

For integrators

  • PMD 7 is a major release where many things have been moved or rewritten.
  • All integrators will require some level of change to adapt to the change in the API.
  • For more details look at the deprecations notes of the past PMD 6 releases.
  • The PMD Ant tasks, which were previously in the module pmd-core has been moved into its own module pmd-ant
  • The CLI classes have also been moved out of pmd-core into its own module pmd-cli. The old entry point, the main class PMD is gone.

🚨 API

The API of PMD has been growing over the years and needed some cleanup. The goal is, to have a clear separation between a well-defined API and the implementation, which is internal. This should help us in future development.

This however entails some incompatibilities and deprecations, see also the sections New API support guidelines and API removals below.

New API support guidelines

Until now, all released public members and types were implicitly considered part of PMD’s public API, including inheritance-specific members (protected members, abstract methods). We have maintained those APIs with the goal to preserve full binary compatibility between minor releases, only breaking those APIs infrequently, for major releases.

In order to allow PMD to move forward at a faster pace, this implicit contract will be invalidated with PMD 7.0.0. We now introduce more fine-grained distinctions between the type of compatibility support we guarantee for our libraries, and ways to make them explicit to clients of PMD.

.internal packages and @InternalApi annotation

Internal API is meant for use only by the main PMD codebase. Internal types and methods may be modified in any way, or even removed, at any time.

Any API in a package that contains an .internal segment is considered internal. The @InternalApi annotation will be used for APIs that have to live outside of these packages, e.g. methods of a public type that shouldn’t be used outside of PMD (again, these can be removed anytime).

@ReservedSubclassing

Types marked with the @ReservedSubclassing annotation are only meant to be subclassed by classes within PMD. As such, we may add new abstract methods, or remove protected methods, at any time. All published public members remain supported. The annotation is not inherited, which means a reserved interface doesn’t prevent its implementors to be subclassed.

@Experimental

APIs marked with the @Experimental annotation at the class or method level are subject to change. They can be modified in any way, or even removed, at any time. You should not use or rely on them in any production code. They are purely to allow broad testing and feedback.

@Deprecated

APIs marked with the @Deprecated annotation at the class or method level will remain supported until the next major release, but it is recommended to stop using them.

Small Changes and cleanups

  • #1648: [apex,vf] Remove CodeClimate dependency - Robert Sösemann Properties “cc_categories”, “cc_remediation_points_multiplier”, “cc_block_highlighting” can no longer be overridden in rulesets. They were deprecated without replacement.

  • The old GUI applications accessible through run.sh designerold and run.sh bgastviewer (and corresponding Batch scripts) have been removed from the PMD distribution. Please use the newer rule designer with pmd designer. The corresponding classes in packages java.net.sourceforge.pmd.util.viewer and java.net.sourceforge.pmd.util.designer have all been removed.

  • All API related to XPath support has been moved to the package net.sourceforge.pmd.lang.rule.xpath. This includes API that was previously dispersed over net.sourceforge.pmd.lang, net.sourceforge.pmd.lang.ast.xpath, net.sourceforge.pmd.lang.rule.xpath, net.sourceforge.pmd.lang.rule, and various language-specific packages (which were made internal).

  • The implementation of the Ant integration has been moved from the module pmd-core to a new module pmd-ant. This involves classes in package net.sourceforge.pmd.ant. The ant CPDTask class net.sourceforge.pmd.cpd.CPDTask has been moved into the same package net.sourceforge.pmd.ant. You’ll need to update your taskdef entries in your build.xml files with the FQCN net.sourceforge.pmd.ant.CPDTask if you use it anywhere.

  • Utility classes in net.sourceforge.pmd.util, that have previously marked as @InternalApi have been finally moved to net.sourceforge.pmd.internal.util. This includes ClasspathClassLoader, FileFinder, FileUtil, and IOUtil.

  • The following utility classes in net.sourceforge.pmd.util are now considered public API:
  • Moved the two classes AntlrTokenizer and JavaCCTokenizer from internal package into package net.sourceforge.pmd.cpd.impl. These two classes are part of the API and are base classes for CPD language implementations. Since 7.0.0-rc2.
  • AntlrBaseRule is gone in favor of AbstractVisitorRule. Since 7.0.0-rc2.
  • The classes KotlinInnerNode and SwiftInnerNode are package-private now. Since 7.0.0-rc2.

XPath 3.1 support

Support for XPath versions 1.0, 1.0-compatibility was removed, support for XPath 2.0 is deprecated. The default (and only) supported XPath version is now XPath 3.1. This version of the XPath language is mostly identical to XPath 2.0.

Notable changes:

  • The deprecated support for sequence-valued attributes is removed. Sequence-valued properties are still supported.
  • Refer to the Saxonica documentation for an introduction to new features in XPath 3.1.

Node stream API for AST traversal

This version includes a powerful API to navigate trees, similar in usage to the Java 8 Stream API:

node.descendants(ASTMethodCall.class)
    .filter(m -> "toString".equals(m.getMethodName()))
    .map(m -> m.getQualifier())
    .filter(q -> TypeTestUtil.isA(String.class, q))
    .foreach(System.out::println);

A pipeline like shown here traverses the tree lazily, which is more efficient than traversing eagerly to put all descendants in a list. It is also much easier to change than the old imperative way.

To make this API as accessible as possible, the Node interface has been fitted with new methods producing node streams. Those methods replace previous tree traversal methods like Node#findDescendantsOfType. In all cases, they should be more efficient and more convenient.

See NodeStream for more details.

Contributors: Clément Fournier (@oowekyala)

Metrics framework

The metrics framework has been made simpler and more general.

  • The metric interface takes an additional type parameter, representing the result type of the metric. This is usually Integer or Double. It avoids widening the result to a double just to narrow it down.

    This makes it so, that Double.NaN is not an appropriate sentinel value to represent “not supported” anymore. Instead, computeFor may return null in that case (or a garbage value). The value null may have caused problems with the narrowing casts, which through unboxing, might have thrown an NPE. But when we deprecated the language-specific metrics façades to replace them with the generic MetricsUtil, we took care of making the new methods throw an exception if the metric cannot be computed on the parameter. This forces you to guard calls to MetricsUtil::computeMetric with something like if (metric.supports(node)). If you’re following this pattern, then you won’t observe the undefined behavior.

  • The MetricKey interface is not so useful and has been merged into the Metric interface and removed. So the Metric interface has the new method String name().

  • The framework is not tied to at most 2 node types per language anymore. Previously those were nodes for classes and for methods/constructors. Instead, many metrics support more node types. For example, NCSS can be computed on any code block.

    For that reason, keeping around a hard distinction between “class metrics” and “operation metrics” is not useful. So in the Java framework for example, we removed the interfaces JavaClassMetric, JavaOperationMetric, abstract classes for those, JavaClassMetricKey, and JavaOperationMetricKey. Metric constants are now all inside the JavaMetrics utility class. The same was done in the Apex framework.

    We don’t really need abstract classes for metrics now. So AbstractMetric is also removed from pmd-core. There is a factory method on the Metric interface to create a metric easily.

  • This makes it so, that LanguageMetricsProvider does not need type parameters. It can just return a Set<Metric<?, ?>> to list available metrics.

  • Signatures, their implementations, and the interface SignedNode have been removed. Node streams allow replacing their usages very easily.

Testing framework

  • PMD 7 has been upgraded to use JUnit 5 only. That means, that JUnit4 related classes have been removed, namely
    • net.sourceforge.pmd.testframework.PMDTestRunner
    • net.sourceforge.pmd.testframework.RuleTestRunner
    • net.sourceforge.pmd.testframework.TestDescriptor
  • Rule tests, that use SimpleAggregatorTst or PmdRuleTst work as before without change, but use now JUnit5 under the hood. If you added additional JUnit4 tests to your rule test classes, then you’ll need to upgrade them to use JUnit5.

Language Lifecycle and Language Properties

  • Language modules now provide a proper lifecycle and can store global information. This enables the implementation of multifile analysis.
  • Language modules can define custom language properties which can be set via environment variables. This allows to add and use language specific configuration options without the need to change pmd-core.

The documentation page has been updated: Adding a new language with JavaCC and Adding a new language with ANTLR

Related issue: [core] Language lifecycle (#3782)

API removals

6.55.0

Go

  • The LanguageModule of Go, that only supports CPD execution, has been deprecated. This language is not fully supported by PMD, so having a language module does not make sense. The functionality of CPD is not affected by this change. The following class has been deprecated and will be removed with PMD 7.0.0:

Java

  • Support for Java 18 preview language features have been removed. The version “18-preview” is no longer available.
  • The experimental class net.sourceforge.pmd.lang.java.ast.ASTGuardedPattern has been removed.

6.54.0

PMD CLI

  • PMD now supports a new --relativize-paths-with flag (or short -z), which replaces --short-names. It serves the same purpose: Shortening the pathnames in the reports. However, with the new flag it’s possible to explicitly define one or more pathnames that should be used as the base when creating relative paths. The old flag --short-names is deprecated.

Deprecated APIs

For removal

Internal APIs

Experimental APIs

  • CPDReport has a new method which limited mutation of a given report:
    • filterMatches creates a new CPD report with some matches removed with a given predicate based filter.

6.53.0

Deprecated APIs

For removal

These classes / APIs have been deprecated and will be removed with PMD 7.0.0.

6.52.0

PMD CLI

  • PMD now supports a new --use-version flag, which receives a language-version pair (such as java-8 or apex-54). This supersedes the usage of -language / -l and -version / -v, allowing for multiple versions to be set in a single run. PMD 7 will completely remove support for -language and -version in favor of this new flag.

  • Support for -V is being deprecated in favor of --verbose in preparation for PMD 7. In PMD 7, -v will enable verbose mode and -V will show the PMD version for consistency with most Unix/Linux tools.

  • Support for -min is being deprecated in favor of --minimum-priority for consistency with most Unix/Linux tools, where -min would be equivalent to -m -i -n.

CPD CLI

  • CPD now supports using -d or --dir as an alias to --files, in favor of consistency with PMD. PMD 7 will remove support for --files in favor of these new flags.

Linux run.sh parameters

  • Using run.sh cpdgui will now warn about it being deprecated. Use run.sh cpd-gui instead.

  • The old designer (run.sh designerold) is completely deprecated and will be removed in PMD 7. Switch to the new JavaFX designer: run.sh designer.

  • The old visual AST viewer (run.sh bgastviewer) is completely deprecated and will be removed in PMD 7. Switch to the new JavaFX designer: run.sh designer for a visual tool, or use run.sh ast-dump for a text-based alternative.

Deprecated API

6.51.0

No changes.

6.50.0

CPD CLI

  • CPD now supports the --ignore-literal-sequences argument when analyzing Lua code.

6.49.0

Deprecated API

6.48.0

CPD CLI

  • CPD has a new CLI option --debug. This option has the same behavior as in PMD. It enables more verbose logging output.

Rule Test Framework

  • The module “pmd-test”, which contains support classes to write rule tests, now requires Java 8. If you depend on this module for testing your own custom rules, you’ll need to make sure to use at least Java 8.
  • The new module “pmd-test-schema” contains now the XSD schema and the code to parse the rule test XML files. The schema has been extracted in order to easily share it with other tools like the Rule Designer or IDE plugins.
  • Test schema changes:
    • The attribute isRegressionTest of test-code is deprecated. The new attribute disabled should be used instead for defining whether a rule test should be skipped or not.
    • The attributes reinitializeRule and useAuxClasspath of test-code are deprecated and assumed true. They will not be replaced.
    • The new attribute focused of test-code allows disabling all tests except the focused one temporarily.
  • More information about the rule test framework can be found in the documentation: Testing your rules

Deprecated API

  • The experimental Java AST class ASTGuardedPattern has been deprecated and will be removed. It was introduced for Java 17 and Java 18 Preview as part of pattern matching for switch, but it is no longer supported with Java 19 Preview.
  • The interface CPDRenderer is deprecated. For custom CPD renderers the new interface CPDReportRenderer should be used.
  • The class TestDescriptor is deprecated, replaced with RuleTestDescriptor.
  • Many methods of RuleTst have been deprecated as internal API.

Experimental APIs

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

6.47.0

No changes.

6.46.0

Deprecated ruleset references

Ruleset references with the following formats are now deprecated and will produce a warning when used on the CLI or in a ruleset XML file:

  • <lang-name>-<ruleset-name>, eg java-basic, which resolves to rulesets/java/basic.xml
  • the internal release number, eg 600, which resolves to rulesets/releases/600.xml

Use the explicit forms of these references to be compatible with PMD 7.

Deprecated API

  • toString is now deprecated. The format of this method will remain the same until PMD 7. The deprecation is intended to steer users away from relying on this format, as it may be changed in PMD 7.
  • getInputPaths and setInputPaths are now deprecated. A new set of methods have been added, which use lists and do not rely on comma splitting.

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

6.45.0

Experimental APIs

  • Report has two new methods which allow limited mutations of a given report:
    • Report#filterViolations creates a new report with some violations removed with a given predicate based filter.
    • Report#union can combine two reports into a single new Report.
  • net.sourceforge.pmd.util.Predicate will be replaced in PMD7 with the standard Predicate interface from java8.
  • The module pmd-html is entirely experimental right now. Anything in the package net.sourceforge.pmd.lang.html should be used cautiously.

6.44.0

Deprecated API

Experimental APIs

  • Together with the new programmatic API the interface TextFile has been added as experimental. It intends to replace DataSource and SourceCode in the long term.

    This interface will change in PMD 7 to support read/write operations and other things. You don’t need to use it in PMD 6, as FileCollector decouples you from this. A file collector is available through PmdAnalysis#files.

6.43.0

Deprecated API

Some API deprecations were performed in core PMD classes, to improve compatibility with PMD 7.

  • Report: the constructor and other construction methods like addViolation or createReport
  • RuleContext: all constructors, getters and setters. A new set of stable methods, matching those in PMD 7, was added to replace the addViolation overloads of AbstractRule. In PMD 7, RuleContext will be the API to report violations, and it can already be used as such in PMD 6.
  • The field configuration is unused and will be removed.

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

Changed API

It is now forbidden to report a violation:

  • With a null node
  • With a null message
  • With a null set of format arguments (prefer a zero-length array)

Note that the message is set from the XML rule declaration, so this is only relevant if you instantiate rules manually.

RuleContext now requires setting the current rule before calling apply. This is done automatically by RuleSet#apply and such. Creating and configuring a RuleContext manually is strongly advised against, as the lifecycle of RuleContext will change drastically in PMD 7.

6.42.0

No changes.

6.41.0

Command Line Interface

The command line options for PMD and CPD now use GNU-syle long options format. E.g. instead of -rulesets the preferred usage is now --rulesets. Alternatively one can still use the short option -R. Some options also have been renamed to a more consistent casing pattern at the same time (--fail-on-violation instead of -failOnViolation). The old single-dash options are still supported but are deprecated and will be removed with PMD 7. This change makes the command line interface more consistent within PMD and also less surprising compared to other cli tools.

The changes in detail for PMD:

old option new option
-rulesets --rulesets (or -R)
-uri --uri
-dir --dir (or -d)
-filelist --file-list
-ignorelist --ignore-list
-format --format (or -f)
-debug --debug
-verbose --verbose
-help --help
-encoding --encoding
-threads --threads
-benchmark --benchmark
-stress --stress
-shortnames --short-names
-showsuppressed --show-suppressed
-suppressmarker --suppress-marker
-minimumpriority --minimum-priority
-property --property
-reportfile --report-file
-force-language --force-language
-auxclasspath --aux-classpath
-failOnViolation --fail-on-violation
--failOnViolation --fail-on-violation
-norulesetcompatibility --no-ruleset-compatibility
-cache --cache
-no-cache --no-cache

The changes in detail for CPD:

old option new option
--failOnViolation --fail-on-violation
-failOnViolation --fail-on-violation
--filelist --file-list

6.40.0

Experimental APIs

  • The interface ASTCommentContainer has been added to the Apex AST. It provides a way to check whether a node contains at least one comment. Currently this is only implemented for ASTCatchBlockStatement and used by the rule EmptyCatchBlock. This information is also available via XPath attribute @ContainsComment.

6.39.0

No changes.

6.38.0

No changes.

6.37.0

PMD CLI

  • PMD has a new CLI option -force-language. With that a language can be forced to be used for all input files, irrespective of filenames. When using this option, the automatic language selection by extension is disabled and all files are tried to be parsed with the given language. Parsing errors are ignored and unparsable files are skipped.

    This option allows to use the xml language for files, that don’t use xml as extension. See also the examples on PMD CLI reference.

Experimental APIs

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

6.36.0

No changes.

6.35.0

Deprecated API

6.34.0

No changes.

6.33.0

No changes.

6.32.0

Experimental APIs

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

  • The protected or public member of the Java rule AvoidUsingHardCodedIPRule are deprecated and considered to be internal API. They will be removed with PMD 7.

6.31.0

Deprecated API

Experimental APIs

  • The method GenericToken#getKind has been added as experimental. This unifies the token interface for both JavaCC and Antlr. The already existing method AntlrToken#getKind is therefore experimental as well. The returned constant depends on the actual language and might change whenever the grammar of the language is changed.

6.30.0

Deprecated API

Around RuleSet parsing

Around the PMD class

Many classes around PMD’s entry point (PMD) have been deprecated as internal, including:

Miscellaneous

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

6.29.0

No changes.

6.28.0

Deprecated API

For removal

6.27.0

  • XML rule definition in rulesets: In PMD 7, the language attribute will be required on all rule elements that declare a new rule. Some base rule classes set the language implicitly in their constructor, and so this is not required in all cases for the rule to work. But this behavior will be discontinued in PMD 7, so missing language attributes are now reported as a forward compatibility warning.

Deprecated API

For removal

6.26.0

Deprecated API

For removal

6.25.0

  • The maven module net.sourceforge.pmd:pmd-scala is deprecated. Use net.sourceforge.pmd:pmd-scala_2.13 or net.sourceforge.pmd:pmd-scala_2.12 instead.

  • Rule implementation classes are internal API and should not be used by clients directly. The rules should only be referenced via their entry in the corresponding category ruleset (e.g. <rule ref="category/java/bestpractices.xml/AbstractClassWithoutAbstractMethod" />).

    While we definitely won’t move or rename the rule classes in PMD 6.x, we might consider changes in PMD 7.0.0 and onwards.

Deprecated APIs

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

For removal

6.24.0

Deprecated APIs

Experimental APIs

Note: Experimental APIs are identified with the annotation Experimental, see its javadoc for details

6.23.0

Deprecated APIs

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

In ASTs

As part of the changes we’d like to do to AST classes for 7.0.0, we would like to hide some methods and constructors that rule writers should not have access to. The following usages are now deprecated in the Apex, Javascript, PL/SQL, Scala and Visualforce ASTs:

  • Manual instantiation of nodes. Constructors of node classes are deprecated and marked InternalApi. Nodes should only be obtained from the parser, which for rules, means that they never need to instantiate node themselves. Those constructors will be made package private with 7.0.0.
  • Subclassing of abstract node classes, or usage of their type. The base classes are internal API and will be hidden in version 7.0.0. You should not couple your code to them.
  • In the meantime you should use interfaces like VfNode or Node, or the other published interfaces in this package, to refer to nodes generically.
  • Concrete node classes will be made final with 7.0.0.
  • Setters found in any node class or interface. Rules should consider the AST immutable. We will make those setters package private with 7.0.0.
  • The implementation classes of Parser (eg VfParser) are deprecated and should not be used directly. Use LanguageVersionHandler#getParser instead.
  • The implementation classes of TokenManager (eg VfTokenManager) are deprecated and should not be used outside of our implementation. This also affects CPD-only modules.

These deprecations are added to the following language modules in this release. Please look at the package documentation to find out the full list of deprecations.

These deprecations have already been rolled out in a previous version for the following languages:

Outside of these packages, these changes also concern the following TokenManager implementations, and their corresponding Parser if it exists (in the same package):

In the Java AST the following attributes are deprecated and will issue a warning when used in XPath rules:

For removal

6.22.0

Deprecated APIs

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

For removal

In ASTs (JSP)

As part of the changes we’d like to do to AST classes for 7.0.0, we would like to hide some methods and constructors that rule writers should not have access to. The following usages are now deprecated in the JSP AST (with other languages to come):

  • Manual instantiation of nodes. Constructors of node classes are deprecated and marked InternalApi. Nodes should only be obtained from the parser, which for rules, means that they never need to instantiate node themselves. Those constructors will be made package private with 7.0.0.
  • Subclassing of abstract node classes, or usage of their type. The base classes are internal API and will be hidden in version 7.0.0. You should not couple your code to them.
  • In the meantime you should use interfaces like JspNode or Node, or the other published interfaces in this package, to refer to nodes generically.
  • Concrete node classes will be made final with 7.0.0.
  • Setters found in any node class or interface. Rules should consider the AST immutable. We will make those setters package private with 7.0.0.
  • The class JspParser is deprecated and should not be used directly. Use LanguageVersionHandler#getParser instead.

Please look at net.sourceforge.pmd.lang.jsp.ast to find out the full list of deprecations.

In ASTs (Velocity)

As part of the changes we’d like to do to AST classes for 7.0.0, we would like to hide some methods and constructors that rule writers should not have access to. The following usages are now deprecated in the VM AST (with other languages to come):

  • Manual instantiation of nodes. Constructors of node classes are deprecated and marked InternalApi. Nodes should only be obtained from the parser, which for rules, means that they never need to instantiate node themselves. Those constructors will be made package private with 7.0.0.
  • Subclassing of abstract node classes, or usage of their type. The base classes are internal API and will be hidden in version 7.0.0. You should not couple your code to them.
  • In the meantime you should use interfaces like VmNode or Node, or the other published interfaces in this package, to refer to nodes generically.
  • Concrete node classes will be made final with 7.0.0.
  • Setters found in any node class or interface. Rules should consider the AST immutable. We will make those setters package private with 7.0.0.
  • The package net.sourceforge.pmd.lang.vm.directive as well as the classes DirectiveMapper and LogUtil are deprecated for removal. They were only used internally during parsing.
  • The class VmParser is deprecated and should not be used directly. Use LanguageVersionHandler#getParser instead.

Please look at net.sourceforge.pmd.lang.vm.ast to find out the full list of deprecations.

PLSQL AST

The production and node ASTCursorBody was unnecessary, not used and has been removed. Cursors have been already parsed as ASTCursorSpecification.

6.21.0

Deprecated APIs

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

For removal

6.20.0

No changes.

6.19.0

Deprecated APIs

For removal

Internal APIs

6.18.0

Changes to Renderer

  • Each renderer has now a new method Renderer#setUseShortNames which is used for implementing the “shortnames” CLI option. The method is automatically called by PMD, if this CLI option is in use. When rendering filenames to the report, the new helper method AbstractRenderer#determineFileName should be used. This will change the filename to a short name, if the CLI option “shortnames” is used.

    Not adjusting custom renderers will make them render always the full file names and not honoring the CLI option “shortnames”.

Deprecated APIs

For removal

Internal APIs

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

6.17.0

No changes.

6.16.0

Deprecated APIs

Reminder: Please don’t use members marked with the annotation InternalApi, as they will likely be removed, hidden, or otherwise intentionally broken with 7.0.0.

In ASTs

As part of the changes we’d like to do to AST classes for 7.0.0, we would like to hide some methods and constructors that rule writers should not have access to. The following usages are now deprecated in the Java AST (with other languages to come):

  • Manual instantiation of nodes. Constructors of node classes are deprecated and marked InternalApi. Nodes should only be obtained from the parser, which for rules, means that never need to instantiate node themselves. Those constructors will be made package private with 7.0.0.
  • Subclassing of abstract node classes, or usage of their type. Version 7.0.0 will bring a new set of abstractions that will be public API, but the base classes are and will stay internal. You should not couple your code to them.
    • In the meantime you should use interfaces like JavaNode or Node, or the other published interfaces in this package, to refer to nodes generically.
    • Concrete node classes will be made final with 7.0.0.
  • Setters found in any node class or interface. Rules should consider the AST immutable. We will make those setters package private with 7.0.0.

Please look at net.sourceforge.pmd.lang.java.ast to find out the full list of deprecations.

6.15.0

Deprecated APIs

For removal

6.14.0

No changes.

6.13.0

Command Line Interface

The start scripts run.sh, pmd.bat and cpd.bat support the new environment variable PMD_JAVA_OPTS. This can be used to set arbitrary JVM options for running PMD, such as memory settings (e.g. PMD_JAVA_OPTS=-Xmx512m) or enable preview language features (e.g. PMD_JAVA_OPTS=--enable-preview).

The previously available variables such as OPTS or HEAPSIZE are deprecated and will be removed with PMD 7.0.0.

Deprecated API

  • CodeClimateRule is deprecated in 7.0.0 because it was unused for 2 years and created an unwanted dependency. Properties “cc_categories”, “cc_remediation_points_multiplier”, “cc_block_highlighting” will also be removed. See #1702 for more.

  • The Apex ruleset rulesets/apex/ruleset.xml has been deprecated and will be removed in 7.0.0. Please use the new quickstart ruleset rulesets/apex/quickstart.xml instead.

6.12.0

No changes.

6.11.0

6.10.0

Properties framework

The properties framework is about to get a lifting, and for that reason, we need to deprecate a lot of APIs to remove them in 7.0.0. The proposed changes to the API are described on the wiki

Changes to how you define properties

Here’s an example:

// Before 7.0.0, these are equivalent:
IntegerProperty myProperty = new IntegerProperty("score", "Top score value", 1, 100, 40, 3.0f);
IntegerProperty myProperty = IntegerProperty.named("score").desc("Top score value").range(1, 100).defaultValue(40).uiOrder(3.0f);

// They both map to the following in 7.0.0
PropertyDescriptor<Integer> myProperty = PropertyFactory.intProperty("score").desc("Top score value").require(inRange(1, 100)).defaultValue(40);

You’re highly encouraged to migrate to using this new API as soon as possible, to ease your migration to 7.0.0.

Architectural simplifications

Changes to the PropertyDescriptor interface

  • preferredRowCount is deprecated with no intended replacement. It was never implemented, and does not belong in this interface. The methods uiOrder and compareTo(PropertyDescriptor) are deprecated for the same reason. These methods mix presentation logic with business logic and are not necessary for PropertyDescriptors to work. PropertyDescriptor will not extend Comparable<PropertyDescriptor> anymore come 7.0.0.
  • The method propertyErrorFor is deprecated and will be removed with no intended replacement. It’s really just a shortcut for prop.errorFor(rule.getProperty(prop)).
  • T valueFrom(String) and String asDelimitedString(T) are deprecated and will be removed. These were used to serialize and deserialize properties to/from a string, but 7.0.0 will introduce a more flexible XML syntax which will make them obsolete.
  • isMultiValue and type are deprecated and won’t be replaced. The new XML syntax will remove the need for a divide between multi- and single-value properties, and will allow arbitrary types to be represented. Since arbitrary types may be represented, type will become obsolete as it can’t represent generic types, which will nevertheless be representable with the XML syntax. It was only used for documentation, but a new way to document these properties exhaustively will be added with 7.0.0.
  • errorFor is deprecated as its return type will be changed to Optional<String> with the shift to Java 8.

Deprecated APIs

For internalization

For removal

All these are deprecated because those nodes may declare several variables at once, possibly
with different types (and obviously with different names). They both implement `Iterator<`<a href="https://docs.pmd-code.org/apidocs/pmd-java/7.0.0-rc2/net/sourceforge/pmd/lang/java/ast/ASTVariableDeclaratorId.html#"><code>ASTVariableDeclaratorId</code></a>`>`
though, so you should iterate on each declared variable. See [#910](https://github.com/pmd/pmd/issues/910).

6.9.0

No changes.

6.8.0

  • A couple of methods and fields in net.sourceforge.pmd.properties.AbstractPropertySource have been deprecated, as they are replaced by already existing functionality or expose internal implementation details: propertyDescriptors, propertyValuesByDescriptor, copyPropertyDescriptors(), copyPropertyValues(), ignoredProperties(), usesDefaultValues(), useDefaultValueFor().

  • Some methods in net.sourceforge.pmd.properties.PropertySource have been deprecated as well: usesDefaultValues(), useDefaultValueFor(), ignoredProperties().

  • The class net.sourceforge.pmd.lang.rule.AbstractDelegateRule has been deprecated and will be removed with PMD 7.0.0. It is internally only in use by RuleReference.

  • The default constructor of net.sourceforge.pmd.lang.rule.RuleReference has been deprecated and will be removed with PMD 7.0.0. RuleReferences should only be created by providing a Rule and a RuleSetReference. Furthermore the following methods are deprecated: setRuleReference(), hasOverriddenProperty(), usesDefaultValues(), useDefaultValueFor().

6.7.0

  • All classes in the package net.sourceforge.pmd.lang.dfa.report have been deprecated and will be removed with PMD 7.0.0. This includes the class net.sourceforge.pmd.lang.dfa.report.ReportTree. The reason is, that this class is very specific to Java and not suitable for other languages. It has only been used for YAHTMLRenderer, which has been rewritten to work without these classes.

  • The nodes RUNSIGNEDSHIFT and RSIGNEDSHIFT are deprecated and will be removed from the AST with PMD 7.0.0. These represented the operator of ShiftExpression in two cases out of three, but they’re not needed and make ShiftExpression inconsistent. The operator of a ShiftExpression is now accessible through ShiftExpression#getOperator.

6.5.0

  • The utility class net.sourceforge.pmd.lang.java.ast.CommentUtil has been deprecated and will be removed with PMD 7.0.0. Its methods have been intended to parse javadoc tags. A more useful solution will be added around the AST node FormalComment, which contains as children JavadocElement nodes, which in turn provide access to the JavadocTag.

    All comment AST nodes (FormalComment, MultiLineComment, SingleLineComment) have a new method getFilteredComment() which provide access to the comment text without the leading /* markers.

  • The method AbstractCommentRule.tagsIndicesIn() has been deprecated and will be removed with PMD 7.0.0. It is not very useful, since it doesn’t extract the information in a useful way. You would still need check, which tags have been found, and with which data they might be accompanied.

6.4.0

  • The following classes in package net.sourceforge.pmd.benchmark have been deprecated: Benchmark, Benchmarker, BenchmarkReport, BenchmarkResult, RuleDuration, StringBuilderCR and TextReport. Their API is not supported anymore and is disconnected from the internals of PMD. Use the newer API based around TimeTracker instead, which can be found in the same package.
  • The class net.sourceforge.pmd.lang.java.xpath.TypeOfFunction has been deprecated. Use the newer TypeIsFunction in the same package.
  • The typeof methods in net.sourceforge.pmd.lang.java.xpath.JavaFunctions have been deprecated. Use the newer typeIs method in the same class instead..
  • The methods isA, isEither and isNeither of net.sourceforge.pmd.lang.java.typeresolution.TypeHelper. Use the new isExactlyAny and isExactlyNone methods in the same class instead.

6.2.0

  • The static method PMDParameters.transformParametersIntoConfiguration(PMDParameters) is now deprecated, for removal in 7.0.0. The new instance method PMDParameters.toConfiguration() replaces it.

  • The method ASTConstructorDeclaration.getParameters() has been deprecated in favor of the new method getFormalParameters(). This method is available for both ASTConstructorDeclaration and ASTMethodDeclaration.

6.1.0

  • The method getXPathNodeName is added to the Node interface, which removes the use of the toString of a node to get its XPath element name (see #569).
    • The default implementation provided in AbstractNode, will be removed with 7.0.0
    • With 7.0.0, the Node.toString method will not necessarily provide its XPath node name anymore.

  • The interface net.sourceforge.pmd.cpd.Renderer has been deprecated. A new interface net.sourceforge.pmd.cpd.renderer.CPDRenderer has been introduced to replace it. The main difference is that the new interface is meant to render directly to a java.io.Writer rather than to a String. This allows to greatly reduce the memory footprint of CPD, as on large projects, with many duplications, it was causing OutOfMemoryErrors (see #795).

    net.sourceforge.pmd.cpd.FileReporter has also been deprecated as part of this change, as it’s no longer needed.

6.0.1

  • The constant net.sourceforge.pmd.PMD.VERSION has been deprecated and will be removed with PMD 7.0.0. Please use net.sourceforge.pmd.PMDVersion.VERSION instead.