Edit me

??-??-2018 - 6.8.0

The PMD team is pleased to announce PMD 6.8.0.

This is a minor release.

Table Of Contents

New and noteworthy

Drawing a line between private and public API

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.

The transition

All currently supported APIs will remain so until 7.0.0. All APIs that are to be moved to .internal packages or hidden will be tagged @InternalApi before that major release, and the breaking API changes will be performed in 7.0.0.

Quickstart Ruleset

PMD 6.8.0 provides a first quickstart ruleset for Java, which you can use as a base ruleset to get your custom ruleset started. You can reference it with rulesets/java/quickstart.xml. You are strongly encouraged to create your own ruleset though.

The quickstart ruleset has the intention, to be useful out-of-the-box for many projects. Therefore it references only rules, that are most likely to apply everywhere.

Any feedback would be greatly appreciated.

New Rules

  • The new Apex rule ApexDoc (apex-documentation) enforces the inclusion of ApexDoc on classes, interfaces, properties and methods; as well as some sanity rules for such docs (no missing parameters, parameters’ order, and return value). By default, method overrides and test classes are allowed to not include ApexDoc.

Modified Rules

  • The rule MissingSerialVersionUID (java-errorprone) has been modified in order to recognize also missing serialVersionUID fields in abstract classes, if they are serializable. Each individual class in the inheritance chain needs an own serialVersionUID field. See also Should an abstract class have a serialVersionUID. This change might lead to additional violations in existing code bases.

PLSQL

The grammar for PLSQL has been revamped in order to fully parse SELECT INTO, UPDATE, and DELETE statements. Previously such statements have been simply skipped ahead, now PMD is parsing them, giving access to the individual parts of a SELECT-statement, such as the Where-Clause. This might produce new parsing errors where PMD previously could successfully parse PLSQL code. If this happens, please report a new issue to get this problem fixed.

Fixed Issues

  • apex-bestpractices
    • #1348: [apex] AvoidGlobalModifierRule gives warning even when its a webservice - false positive
  • java-codestyle
    • #1329: [java] FieldNamingConventions: false positive in serializable class with serialVersionUID
    • #1334: [java] LinguisticNaming should support AtomicBooleans
  • java-errorprone
    • #1350: [java] MissingSerialVersionUID false-positive on interfaces
    • #1352: [java] MissingSerialVersionUID false-negative with abstract classes
  • java-performance
    • #1325: [java] False positive in ConsecutiveLiteralAppends
  • plsql
    • #1279: [plsql] Support for SELECT INTO

API Changes

  • 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().

External Contributions