PMD 6.10.0 released

09 December 2018

09-December-2018 - 6.10.0

The PMD team is pleased to announce PMD 6.10.0.

This is a minor release.

Table Of Contents

New and noteworthy

Kotlin support for CPD

Thanks to Maikel Steneker, CPD now supports Kotlin. This means, you can use CPD to find duplicated code in your Kotlin projects.

New Rules

  • The new Java rule UseUnderscoresInNumericLiterals (java-codestyle) verifies that numeric literals over a given length (4 chars by default, but configurable) are using underscores every 3 digits for readability. The rule only applies to Java 7+ codebases.

Modified Rules

Fixed Issues

  • all
    • #1284: [doc] Keep record of every currently deprecated API
    • #1318: [test] Kotlin DSL to ease test writing
    • #1328: [ci] Building docs for release fails
    • #1341: [doc] Documentation Error with Regex Properties
    • #1468: [doc] Missing escaping leads to XSS
    • #1471: [core] XMLRenderer: ProcessingErrors from exceptions without a message missing
    • #1477: [core] Analysis cache fails with wildcard classpath entries
  • java
    • #1460: [java] Intermittent PMD failure : PMD processing errors while no violations reported
  • java-bestpractices
    • #647: [java] JUnitTestsShouldIncludeAssertRule should support this.exception as well as just exception
    • #1435: [java] JUnitTestsShouldIncludeAssert: Support AssertJ soft assertions
  • java-codestyle
    • #1232: [java] Detector for large numbers not separated by _
    • #1372: [java] false positive for UselessQualifiedThis
    • #1440: [java] CommentDefaultAccessModifierRule shows incorrect message
  • java-design
    • #1151: [java] ImmutableField false positive with multiple constructors
    • #1483: [java] Cyclo metric should count conditions of for statements correctly
  • java-errorprone
    • #1512: [java] InvalidSlf4jMessageFormatRule causes NPE in lambda and static blocks
  • plsql
    • #1454: [plsql] ParseException for IF/CASE statement with >=, <=, !=

API Changes

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

External Contributions