Error Prone

AssignmentInOperand

Since: PMD 1.03

Priority: Medium (3)

Avoid assignments in operands; this can make code more complicated and harder to read.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.AssignmentInOperandRule

Example(s):

public void bar() {
    int x = 2;
    if ((x = getX()) == 3) {
      System.out.println("3!");
    }
}

This rule has the following properties:

Use this rule with the default properties by just referencing it:

<rule ref="category/java/errorprone.xml/AssignmentInOperand" />

Use this rule and customize it:

<rule ref="category/java/errorprone.xml/AssignmentInOperand">
    <properties>
        <property name="allowIf" value="false" />
        <property name="allowFor" value="false" />
        <property name="allowWhile" value="false" />
        <property name="allowIncrementDecrement" value="false" />
    </properties>
</rule>

AssignmentToNonFinalStatic

Since: PMD 2.2

Priority: Medium (3)

Identifies a possible unsafe usage of a static field.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.AssignmentToNonFinalStaticRule

Example(s):

public class StaticField {
   static int x;
   public FinalFields(int y) {
    x = y; // unsafe
   }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/AssignmentToNonFinalStatic" />

AvoidAccessibilityAlteration

Since: PMD 4.1

Priority: Medium (3)

Methods such as getDeclaredConstructors(), getDeclaredMethods(), and getDeclaredFields() also return private constructors, methods and fields. These can be made accessible by calling setAccessible(true). This gives access to normally protected data which violates the principle of encapsulation.

This rule detects calls to setAccessible and finds possible accessibility alterations. If the call to setAccessible is wrapped within a PrivilegedAction, then the access alteration is assumed to be deliberate and is not reported.

Note that with Java 17 the Security Manager, which is used for PrivilegedAction execution, is deprecated: JEP 411: Deprecate the Security Manager for Removal. For future-proof code, deliberate access alteration should be suppressed using the usual suppression methods (e.g. by using @SuppressWarnings annotation).

This rule is defined by the following XPath expression:

//MethodCall[
          pmd-java:matchesSig("java.lang.reflect.AccessibleObject#setAccessible(boolean)")
       or pmd-java:matchesSig("_#setAccessible(java.lang.reflect.AccessibleObject[],boolean)")
    ]
    [not(ArgumentList/BooleanLiteral[@True = false()])]
    (: exclude anonymous privileged action classes :)
    [not(ancestor::ConstructorCall[1][pmd-java:typeIs('java.security.PrivilegedAction')]/AnonymousClassDeclaration)]
    (: exclude inner privileged action classes :)
    [not(ancestor::ClassDeclaration[1][pmd-java:typeIs('java.security.PrivilegedAction')])]
    (: exclude privileged action lambdas :)
    [not(ancestor::LambdaExpression[pmd-java:typeIs('java.security.PrivilegedAction')])]

Example(s):

import java.lang.reflect.Constructor;
import java.lang.reflect.Field;
import java.lang.reflect.Method;
import java.security.AccessController;
import java.security.PrivilegedAction;

public class Violation {
    private void invalidSetAccessCalls() throws NoSuchMethodException, SecurityException {
        Constructor<?> constructor = this.getClass().getDeclaredConstructor(String.class);
        // call to forbidden setAccessible
        constructor.setAccessible(true);

        Method privateMethod = this.getClass().getDeclaredMethod("aPrivateMethod");
        // call to forbidden setAccessible
        privateMethod.setAccessible(true);

        // deliberate accessibility alteration
        String privateField = AccessController.doPrivileged(new PrivilegedAction<String>() {
            @Override
            public String run() {
                try {
                    Field field = Violation.class.getDeclaredField("aPrivateField");
                    field.setAccessible(true);
                    return (String) field.get(null);
                } catch (ReflectiveOperationException | SecurityException e) {
                    throw new RuntimeException(e);
                }
            }
        });
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/AvoidAccessibilityAlteration" />

AvoidAssertAsIdentifier

Since: PMD 3.4

Priority: Medium High (2)

Maximum Language Version: Java 1.3

Use of the term assert will conflict with newer versions of Java since it is a reserved word.

Since Java 1.4, the token assert became a reserved word and using it as an identifier will result in a compilation failure for Java 1.4 and later. This rule is therefore only useful for old Java code before Java 1.4. It can be used to identify problematic code prior to a Java update.

This rule is defined by the following XPath expression:

//VariableId[@Name='assert']

Example(s):

public class A {
    public class Foo {
        String assert = "foo";
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/AvoidAssertAsIdentifier" />

AvoidBranchingStatementAsLastInLoop

Since: PMD 5.0

Priority: Medium High (2)

Using a branching statement as the last part of a loop may be a bug, and/or is confusing. Ensure that the usage is not a bug, or consider using another approach.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.AvoidBranchingStatementAsLastInLoopRule

Example(s):

// unusual use of branching statement in a loop
for (int i = 0; i < 10; i++) {
    if (i*i <= 25) {
        continue;
    }
    break;
}

// this makes more sense...
for (int i = 0; i < 10; i++) {
    if (i*i > 25) {
        break;
    }
}

This rule has the following properties:

Use this rule with the default properties by just referencing it:

<rule ref="category/java/errorprone.xml/AvoidBranchingStatementAsLastInLoop" />

Use this rule and customize it:

<rule ref="category/java/errorprone.xml/AvoidBranchingStatementAsLastInLoop">
    <properties>
        <property name="checkBreakLoopTypes" value="for,do,while" />
        <property name="checkContinueLoopTypes" value="for,do,while" />
        <property name="checkReturnLoopTypes" value="for,do,while" />
    </properties>
</rule>

AvoidCallingFinalize

Since: PMD 3.0

Priority: Medium (3)

The method Object.finalize() is called by the garbage collector on an object when garbage collection determines that there are no more references to the object. It should not be invoked by application logic.

Note that Oracle has declared Object.finalize() as deprecated since JDK 9.

This rule is defined by the following XPath expression:

//MethodCall[pmd-java:matchesSig("java.lang.Object#finalize()")]
    (: it's ok inside finalize :)
    [not(SuperExpression and ancestor::*[self::MethodDeclaration or self::Initializer][1][@Name = 'finalize'][@Arity = 0][VoidType])]

Example(s):

void foo() {
    Bar b = new Bar();
    b.finalize();
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/AvoidCallingFinalize" />

AvoidCatchingNPE

Since: PMD 1.8

Priority: Medium (3)

Code should never throw NullPointerExceptions under normal circumstances. A catch block may hide the original error, causing other, more subtle problems later on.

This rule is defined by the following XPath expression:

//CatchClause/CatchParameter/ClassType[pmd-java:typeIsExactly('java.lang.NullPointerException')]

Example(s):

public class Foo {
    void bar() {
        try {
            // do something
        } catch (NullPointerException npe) {
        }
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/AvoidCatchingNPE" />

AvoidCatchingThrowable

Since: PMD 1.2

Priority: Medium (3)

Catching Throwable errors is not recommended since its scope is very broad. It includes runtime issues such as OutOfMemoryError that should be exposed and managed separately.

This rule is defined by the following XPath expression:

//CatchParameter[ClassType[pmd-java:typeIsExactly('java.lang.Throwable')]]/VariableId

Example(s):

public void bar() {
    try {
        // do something
    } catch (Throwable th) {  // should not catch Throwable
        th.printStackTrace();
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/AvoidCatchingThrowable" />

AvoidDecimalLiteralsInBigDecimalConstructor

Since: PMD 3.4

Priority: Medium (3)

One might assume that the result of "new BigDecimal(0.1)" is exactly equal to 0.1, but it is actually equal to .1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or as a binary fraction of any finite length). Thus, the long value that is being passed in to the constructor is not exactly equal to 0.1, appearances notwithstanding.

The (String) constructor, on the other hand, is perfectly predictable: ‘new BigDecimal("0.1")’ is exactly equal to 0.1, as one would expect. Therefore, it is generally recommended that the (String) constructor be used in preference to this one.

This rule is defined by the following XPath expression:

//ConstructorCall[pmd-java:matchesSig('java.math.BigDecimal#new(double)')]

Example(s):

BigDecimal bd = new BigDecimal(1.123);       // loss of precision, this would trigger the rule

BigDecimal bd = new BigDecimal("1.123");     // preferred approach

BigDecimal bd = new BigDecimal(12);          // preferred approach, ok for integer values

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/AvoidDecimalLiteralsInBigDecimalConstructor" />

AvoidDuplicateLiterals

Since: PMD 1.0

Priority: Medium (3)

Code containing duplicate String literals can usually be improved by declaring the String as a constant field.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.AvoidDuplicateLiteralsRule

Example(s):

private void bar() {
     buz("Howdy");
     buz("Howdy");
     buz("Howdy");
     buz("Howdy");
}
private void buz(String x) {}

This rule has the following properties:

Use this rule with the default properties by just referencing it:

<rule ref="category/java/errorprone.xml/AvoidDuplicateLiterals" />

Use this rule and customize it:

<rule ref="category/java/errorprone.xml/AvoidDuplicateLiterals">
    <properties>
        <property name="maxDuplicateLiterals" value="4" />
        <property name="minimumLength" value="3" />
        <property name="skipAnnotations" value="false" />
        <property name="exceptionList" value="" />
    </properties>
</rule>

AvoidEnumAsIdentifier

Since: PMD 3.4

Priority: Medium High (2)

Maximum Language Version: Java 1.4

Use of the term enum will conflict with newer versions of Java since it is a reserved word.

Since Java 1.5, the token enum became a reserved word and using it as an identifier will result in a compilation failure for Java 1.5 and later. This rule is therefore only useful for old Java code before Java 1.5. It can be used to identify problematic code prior to a Java update.

This rule is defined by the following XPath expression:

//VariableId[@Name='enum']

Example(s):

public class A {
    public class Foo {
        String enum = "foo";
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/AvoidEnumAsIdentifier" />

AvoidFieldNameMatchingMethodName

Since: PMD 3.0

Priority: Medium (3)

It can be confusing to have a field name with the same name as a method. While this is permitted, having information (field) and actions (method) is not clear naming. Developers versed in Smalltalk often prefer this approach as the methods denote accessor methods.

This rule is defined by the following XPath expression:

//FieldDeclaration/VariableDeclarator/VariableId
    [some $method in ../../..[self::ClassBody or self::EnumBody]/MethodDeclaration
     satisfies lower-case(@Name) = lower-case($method/@Name)]

Example(s):

public class Foo {
    Object bar;
    // bar is data or an action or both?
    void bar() {
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/AvoidFieldNameMatchingMethodName" />

AvoidFieldNameMatchingTypeName

Since: PMD 3.0

Priority: Medium (3)

It is somewhat confusing to have a field name matching the declaring type name. This probably means that type and/or field names should be chosen more carefully.

This rule is defined by the following XPath expression:

//FieldDeclaration/VariableDeclarator/VariableId
    [lower-case(@Name) = lower-case(ancestor::ClassDeclaration[1]/@SimpleName)]

Example(s):

public class Foo extends Bar {
    int foo;    // There is probably a better name that can be used
}
public interface Operation {
    int OPERATION = 1; // There is probably a better name that can be used
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/AvoidFieldNameMatchingTypeName" />

AvoidInstanceofChecksInCatchClause

Since: PMD 3.0

Priority: Medium (3)

Each caught exception type should be handled in its own catch clause.

This rule is defined by the following XPath expression:

//CatchParameter
    /following-sibling::Block//InfixExpression[@Operator = 'instanceof']
        /VariableAccess[@Name = ./ancestor::Block/preceding-sibling::CatchParameter/@Name]

Example(s):

try { // Avoid this
    // do something
} catch (Exception ee) {
    if (ee instanceof IOException) {
        cleanup();
    }
}

try {  // Prefer this:
    // do something
} catch (IOException ee) {
    cleanup();
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/AvoidInstanceofChecksInCatchClause" />

AvoidLiteralsInIfCondition

Since: PMD 4.2.6

Priority: Medium (3)

Avoid using hard-coded literals in conditional statements. By declaring them as static variables or private members with descriptive names maintainability is enhanced. By default, the literals "-1" and "0" are ignored. More exceptions can be defined with the property "ignoreMagicNumbers".

The rule doesn’t consider deeper expressions by default, but this can be enabled via the property ignoreExpressions. With this property set to false, if-conditions like i == 1 + 5 are reported as well. Note that in that case, the property ignoreMagicNumbers is not taken into account, if there are multiple literals involved in such an expression.

This rule is defined by the following XPath expression:

(: simple case - no deep expressions - this is always executed :)
//IfStatement/*[1]/*[pmd-java:nodeIs('Literal')]
    [not(pmd-java:nodeIs('NullLiteral'))]
    [not(pmd-java:nodeIs('BooleanLiteral'))]
    [empty(index-of(tokenize($ignoreMagicNumbers, '\s*,\s*'), @Image))]
|
(: consider also deeper expressions :)
//IfStatement[$ignoreExpressions = false()]/*[1]//*[not(self::UnaryExpression[@Operator = '-'])]/*[pmd-java:nodeIs('Literal')]
    [not(pmd-java:nodeIs('NullLiteral'))]
    [not(pmd-java:nodeIs('BooleanLiteral'))]
    [empty(index-of(tokenize($ignoreMagicNumbers, '\s*,\s*'), @Image))]
|
(: consider negative literals :)
//IfStatement[$ignoreExpressions = false()]/*[1]//UnaryExpression[@Operator = '-']/*[pmd-java:nodeIs('Literal')]
    [not(pmd-java:nodeIs('NullLiteral'))]
    [not(pmd-java:nodeIs('BooleanLiteral'))]
    [empty(index-of(tokenize($ignoreMagicNumbers, '\s*,\s*'), concat('-', @Image)))]
|
(: consider multiple literals in expressions :)
//IfStatement[$ignoreExpressions = false()]/*[1][count(*[pmd-java:nodeIs('Literal')]
    [not(pmd-java:nodeIs('NullLiteral'))]
    [not(pmd-java:nodeIs('BooleanLiteral'))]) > 1]

Example(s):

private static final int MAX_NUMBER_OF_REQUESTS = 10;

public void checkRequests() {

    if (i == 10) {                        // magic number, buried in a method
      doSomething();
    }

    if (i == MAX_NUMBER_OF_REQUESTS) {    // preferred approach
      doSomething();
    }

    if (aString.indexOf('.') != -1) {}     // magic number -1, by default ignored
    if (aString.indexOf('.') >= 0) { }     // alternative approach

    if (aDouble > 0.0) {}                  // magic number 0.0
    if (aDouble >= Double.MIN_VALUE) {}    // preferred approach

    // with rule property "ignoreExpressions" set to "false"
    if (i == pos + 5) {}  // violation: magic number 5 within an (additive) expression
    if (i == pos + SUFFIX_LENGTH) {} // preferred approach
    if (i == 5 && "none".equals(aString)) {} // 2 violations: magic number 5 and literal "none"
}

This rule has the following properties:

Use this rule with the default properties by just referencing it:

<rule ref="category/java/errorprone.xml/AvoidLiteralsInIfCondition" />

Use this rule and customize it:

<rule ref="category/java/errorprone.xml/AvoidLiteralsInIfCondition">
    <properties>
        <property name="ignoreMagicNumbers" value="-1,0" />
        <property name="ignoreExpressions" value="true" />
    </properties>
</rule>

AvoidLosingExceptionInformation

Since: PMD 4.2.6

Priority: Medium High (2)

Statements in a catch block that invoke accessors on the exception without using the information only add to code size. Either remove the invocation, or use the return result.

This rule is defined by the following XPath expression:

//CatchClause/Block/ExpressionStatement/MethodCall[
    pmd-java:matchesSig("java.lang.Throwable#getMessage()")
    or pmd-java:matchesSig("java.lang.Throwable#getLocalizedMessage()")
    or pmd-java:matchesSig("java.lang.Throwable#getCause()")
    or pmd-java:matchesSig("java.lang.Throwable#getStackTrace()")
    or pmd-java:matchesSig("java.lang.Object#toString()")
]

Example(s):

public void bar() {
    try {
        // do something
    } catch (SomeException se) {
        se.getMessage();
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/AvoidLosingExceptionInformation" />

AvoidMultipleUnaryOperators

Since: PMD 4.2

Priority: Medium High (2)

The use of multiple unary operators may be problematic, and/or confusing. Ensure that the intended usage is not a bug, or consider simplifying the expression.

This rule is defined by the following XPath expression:

(: Only report on the toplevel one :)
                    //UnaryExpression[UnaryExpression and not(parent::UnaryExpression)]

Example(s):

// These are typo bugs, or at best needlessly complex and confusing:
int i = - -1;
int j = + - +1;
int z = ~~2;
boolean b = !!true;
boolean c = !!!true;

// These are better:
int i = 1;
int j = -1;
int z = 2;
boolean b = true;
boolean c = false;

// And these just make your brain hurt:
int i = ~-2;
int j = -~7;

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/AvoidMultipleUnaryOperators" />

AvoidUsingOctalValues

Since: PMD 3.9

Priority: Medium (3)

Integer literals should not start with zero since this denotes that the rest of literal will be interpreted as an octal value.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.AvoidUsingOctalValuesRule

Example(s):

int i = 012;    // set i with 10 not 12
int j = 010;    // set j with 8 not 10
k = i * j;      // set k with 80 not 120

This rule has the following properties:

Use this rule with the default properties by just referencing it:

<rule ref="category/java/errorprone.xml/AvoidUsingOctalValues" />

Use this rule and customize it:

<rule ref="category/java/errorprone.xml/AvoidUsingOctalValues">
    <properties>
        <property name="strict" value="false" />
    </properties>
</rule>

BrokenNullCheck

Since: PMD 3.8

Priority: Medium High (2)

The null check is broken since it will throw a NullPointerException itself. It is likely that you used || instead of && or vice versa.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.BrokenNullCheckRule

Example(s):

public String bar(String string) {
  // should be &&
    if (string!=null || !string.equals(""))
        return string;
  // should be ||
    if (string==null && string.equals(""))
        return string;
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/BrokenNullCheck" />

CallSuperFirst

Since: PMD 4.2.5

Priority: Medium (3)

Super should be called at the start of the method

This rule is defined by the following XPath expression:

//ClassDeclaration
    [
      pmd-java:typeIs('android.app.Activity') or
      pmd-java:typeIs('android.app.Application') or
      pmd-java:typeIs('android.app.Service')
    ]
    //MethodDeclaration
    [
      @Name=('onCreate', 'onConfigurationChanged', 'onPostCreate', 'onPostResume', 'onRestart',
             'onRestoreInstanceState', 'onResume', 'onStart')
    ]
    [not(Block/*[1]/MethodCall[SuperExpression][@MethodName = ancestor::MethodDeclaration/@Name])]

Example(s):

import android.app.Activity;
import android.os.Bundle;

public class DummyActivity extends Activity {
    public void onCreate(Bundle bundle) {
        // missing call to super.onCreate(bundle)
        foo();
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/CallSuperFirst" />

CallSuperLast

Since: PMD 4.2.5

Priority: Medium (3)

Super should be called at the end of the method

This rule is defined by the following XPath expression:

//ClassDeclaration
    [
      pmd-java:typeIs('android.app.Activity') or
      pmd-java:typeIs('android.app.Application') or
      pmd-java:typeIs('android.app.Service')
    ]
    //MethodDeclaration
    [
      @Name=('finish', 'onDestroy', 'onPause', 'onSaveInstanceState', 'onStop', 'onTerminate')
    ]
    [not(Block/*[last()]/MethodCall[SuperExpression][@MethodName = ancestor::MethodDeclaration/@Name])]

Example(s):

import android.app.Activity;

public class DummyActivity extends Activity {
    public void onPause() {
        foo();
        // missing call to super.onPause()
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/CallSuperLast" />

CheckSkipResult

Since: PMD 5.0

Priority: Medium (3)

The skip() method may skip a smaller number of bytes than requested. Check the returned value to find out if it was the case or not.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.CheckSkipResultRule

Example(s):

public class Foo {

   private FileInputStream _s = new FileInputStream("file");

   public void skip(int n) throws IOException {
      _s.skip(n); // You are not sure that exactly n bytes are skipped
   }

   public void skipExactly(int n) throws IOException {
      while (n != 0) {
         long skipped = _s.skip(n);
         if (skipped == 0)
            throw new EOFException();
         n -= skipped;
      }
   }

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/CheckSkipResult" />

ClassCastExceptionWithToArray

Since: PMD 3.4

Priority: Medium (3)

When deriving an array of a specific class from your Collection, one should provide an array of the same class as the parameter of the toArray() method. Doing otherwise will result in a ClassCastException.

This rule is defined by the following XPath expression:

//CastExpression[ArrayType/ClassType[not(pmd-java:typeIsExactly('java.lang.Object'))]]
    /MethodCall[pmd-java:matchesSig("java.util.Collection#toArray()")]

Example(s):

Collection c = new ArrayList();
Integer obj = new Integer(1);
c.add(obj);

    // this would trigger the rule (and throw a ClassCastException if executed)
Integer[] a = (Integer [])c.toArray();

   // this is fine and will not trigger the rule
Integer[] b = (Integer [])c.toArray(new Integer[0]);

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/ClassCastExceptionWithToArray" />

CloneMethodMustBePublic

Since: PMD 5.4.0

Priority: Medium (3)

The java manual says "By convention, classes that implement this interface should override Object.clone (which is protected) with a public method."

This rule is defined by the following XPath expression:

//MethodDeclaration[not(pmd-java:modifiers() = "public")]
    [@Name = 'clone']
    [@Arity = 0]

Example(s):

public class Foo implements Cloneable {
    @Override
    protected Object clone() throws CloneNotSupportedException { // Violation, must be public
    }
}

public class Foo implements Cloneable {
    @Override
    protected Foo clone() { // Violation, must be public
    }
}

public class Foo implements Cloneable {
    @Override
    public Object clone() // Ok
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/CloneMethodMustBePublic" />

CloneMethodMustImplementCloneable

Since: PMD 1.9

Priority: Medium (3)

The method clone() should only be implemented if the class implements the Cloneable interface with the exception of a final method that only throws CloneNotSupportedException.

The rule can also detect, if the class implements or extends a Cloneable class.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.CloneMethodMustImplementCloneableRule

Example(s):

public class MyClass {
 public Object clone() throws CloneNotSupportedException {
  return foo;
 }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/CloneMethodMustImplementCloneable" />

CloneMethodReturnTypeMustMatchClassName

Since: PMD 5.4.0

Priority: Medium (3)

Minimum Language Version: Java 1.5

If a class implements Cloneable the return type of the method clone() must be the class name. That way, the caller of the clone method doesn’t need to cast the returned clone to the correct type.

Note: Such a covariant return type is only possible with Java 1.5 or higher.

This rule is defined by the following XPath expression:

//MethodDeclaration
    [@Name = 'clone']
    [@Arity = 0]
    [ClassType[1]/@SimpleName != ancestor::ClassDeclaration[1]/@SimpleName]

Example(s):

public class Foo implements Cloneable {
    @Override
    protected Object clone() { // Violation, Object must be Foo
    }
}

public class Foo implements Cloneable {
    @Override
    public Foo clone() { //Ok
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/CloneMethodReturnTypeMustMatchClassName" />

CloseResource

Since: PMD 1.2.2

Priority: Medium (3)

Ensure that resources (like java.sql.Connection, java.sql.Statement, and java.sql.ResultSet objects and any subtype of java.lang.AutoCloseable) are always closed after use. Failing to do so might result in resource leaks.

Note: It suffices to configure the super type, e.g. java.lang.AutoCloseable, so that this rule automatically triggers on any subtype (e.g. java.io.FileInputStream). Additionally specifying java.sql.Connection helps in detecting the types, if the type resolution / auxclasspath is not correctly setup.

Note: Since PMD 6.16.0 the default value for the property types contains java.lang.AutoCloseable and detects now cases where the standard java.io.*Stream classes are involved. In order to restore the old behaviour, just remove "AutoCloseable" from the types.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.CloseResourceRule

Example(s):

public class Bar {
    public void withSQL() {
        Connection c = pool.getConnection();
        try {
            // do stuff
        } catch (SQLException ex) {
           // handle exception
        } finally {
            // oops, should close the connection using 'close'!
            // c.close();
        }
    }

    public void withFile() {
        InputStream file = new FileInputStream(new File("/tmp/foo"));
        try {
            int c = file.in();
        } catch (IOException e) {
            // handle exception
        } finally {
            // TODO: close file
        }
    }
}

This rule has the following properties:

Use this rule with the default properties by just referencing it:

<rule ref="category/java/errorprone.xml/CloseResource" />

Use this rule and customize it:

<rule ref="category/java/errorprone.xml/CloseResource">
    <properties>
        <property name="closeTargets" value="" />
        <property name="types" value="java.lang.AutoCloseable,java.sql.Connection,java.sql.Statement,java.sql.ResultSet" />
        <property name="closeAsDefaultTarget" value="true" />
        <property name="allowedResourceTypes" value="java.io.ByteArrayOutputStream,java.io.ByteArrayInputStream,java.io.StringWriter,java.io.CharArrayWriter,java.util.stream.Stream,java.util.stream.IntStream,java.util.stream.LongStream,java.util.stream.DoubleStream" />
        <property name="closeNotInFinally" value="false" />
    </properties>
</rule>

CompareObjectsWithEquals

Since: PMD 3.2

Priority: Medium (3)

Use equals() to compare object references; avoid comparing them with ==.

Since comparing objects with named constants is useful in some cases (eg, when defining constants for sentinel values), the rule ignores comparisons against fields with all-caps name (eg this == SENTINEL), which is a common naming convention for constant fields.

You may allow some types to be compared by reference by listing the exceptions in the typesThatCompareByReference property.

This rule is defined by the following XPath expression:

//InfixExpression
    [@Operator = ("==", "!=")]
    [count(*
        [not(self::NullLiteral)]
        [pmd-java:typeIs('java.lang.Object')]
        [not(some $t in $typesThatCompareByReference satisfies pmd-java:typeIs($t))]
      ) = 2
    ]
    [not(ancestor::MethodDeclaration[1][@Name = "equals"])]
    (: Is not a field access with an all-caps identifier :)
    [not(FieldAccess[upper-case(@Name)=@Name]
     or VariableAccess[upper-case(@Name)=@Name])]

Example(s):

class Foo {
  boolean bar(String a, String b) {
    return a == b;
  }
}

This rule has the following properties:

Use this rule with the default properties by just referencing it:

<rule ref="category/java/errorprone.xml/CompareObjectsWithEquals" />

Use this rule and customize it:

<rule ref="category/java/errorprone.xml/CompareObjectsWithEquals">
    <properties>
        <property name="typesThatCompareByReference" value="java.lang.Enum,java.lang.Class" />
    </properties>
</rule>

ComparisonWithNaN

Since: PMD 6.36.0

Priority: Medium (3)

Reports comparisons with double and float NaN (Not-a-Number) values. These are specified to have unintuitive behavior: NaN is considered unequal to itself. This means a check like someDouble == Double.NaN will always return false, even if someDouble is really the NaN value. To test whether a value is the NaN value, one should instead use Double.isNaN(someDouble) (or Float.isNaN). The != operator should be treated similarly. Finally, comparisons like someDouble <= Double.NaN are nonsensical and will always evaluate to false.

This rule has been renamed from "BadComparison" in PMD 6.36.0.

This rule is defined by the following XPath expression:

//InfixExpression[@Operator = ("==", "!=", "<=", ">=", "<", ">")]/FieldAccess[@Name='NaN' and (pmd-java:typeIs('double') or pmd-java:typeIs('float'))]

Example(s):

boolean x = (y == Double.NaN);

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/ComparisonWithNaN" />

ConfusingArgumentToVarargsMethod

Since: PMD 7.1.0

Priority: Medium (3)

Reports a confusing argument passed to a varargs method.

This can occur when an array is passed as a single varargs argument, when the array type is not exactly the type of array that the varargs method expects. If, that array is a subtype of the component type of the expected array type, then it might not be clear what value the called varargs method will receive. For instance if you have:

void varargs(Object... parm);

and call it like so:

varargs(new String[]{"a"});

it is not clear whether you intended the method to receive the value new Object[]{ new String[] {"a"} } or just new String[] {"a"} (the latter happens). This confusion occurs because String[] is both a subtype of Object[] and of Object. To clarify your intent in this case, use a cast or pass individual elements like so:

// varargs call
// parm will be `new Object[] { "a" }`
varargs("a");

// non-varargs call
// parm will be `new String[] { "a" }`
varargs((Object[]) new String[]{"a"});

// varargs call
// parm will be `new Object[] { new String[] { "a" } }`
varargs((Object) new String[]{"a"});

Another confusing case is when you pass null as the varargs argument. Here it is not clear whether you intended to pass an array with a single null element, or a null array (the latter happens). This can similarly be clarified with a cast.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.ConfusingArgumentToVarargsMethodRule

Example(s):

import java.util.Arrays;

            abstract class C {
                abstract void varargs(Object... args);
                static {
                    varargs(new String[] { "a" });
                    varargs(null);
                }
            }

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/ConfusingArgumentToVarargsMethod" />

ConstructorCallsOverridableMethod

Since: PMD 1.04

Priority: High (1)

Reports calls to overridable methods on this during object initialization. These are invoked on an incompletely constructed object and can be difficult to debug if overridden. This is because the subclass usually assumes that the superclass is completely initialized in all methods. If that is not the case, bugs can appear in the constructor, for instance, some fields that are still null may cause a NullPointerException or be stored somewhere else to blow up later.

To avoid this problem, only use methods that are static, private, or final in constructors. Note that those methods also must not call overridable methods transitively to be safe.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.ConstructorCallsOverridableMethodRule

Example(s):

public class SeniorClass {
  public SeniorClass(){
      toString(); //may throw NullPointerException if overridden
  }
  public String toString(){
    return "IAmSeniorClass";
  }
}
public class JuniorClass extends SeniorClass {
  private String name;
  public JuniorClass(){
    super(); //Automatic call leads to NullPointerException
    name = "JuniorClass";
  }
  public String toString(){
    return name.toUpperCase();
  }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/ConstructorCallsOverridableMethod" />

DetachedTestCase

Since: PMD 6.13.0

Priority: Medium (3)

The method appears to be a test case since it has public or default visibility, non-static access, no arguments, no return value, has no annotations, but is a member of a class that has one or more JUnit test cases. If it is a utility method, it should likely have private visibility. If it is an ignored test, it should be annotated with @Test and @Ignore.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.DetachedTestCaseRule

Example(s):

public class MyTest {
    @Test
    public void someTest() {
    }

    // violation: Not annotated
    public void someOtherTest () {
    }

}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/DetachedTestCase" />

DoNotCallGarbageCollectionExplicitly

Since: PMD 4.2

Priority: Medium High (2)

Calls to System.gc(), Runtime.getRuntime().gc(), and System.runFinalization() are not advised. Code should have the same behavior whether the garbage collection is disabled using the option -Xdisableexplicitgc or not.

Moreover, "modern" JVMs do a very good job handling garbage collections. If memory usage issues unrelated to memory leaks develop within an application, it should be dealt with JVM options rather than within the code itself.

This rule is defined by the following XPath expression:

//MethodCall[
       pmd-java:matchesSig("java.lang.System#gc()")
    or pmd-java:matchesSig("java.lang.Runtime#gc()")
    or pmd-java:matchesSig("java.lang.System#runFinalization()")
    or pmd-java:matchesSig("java.lang.Runtime#runFinalization()")
]

Example(s):

public class GCCall {
    public GCCall() {
        // Explicit gc call !
        System.gc();
    }

    public void doSomething() {
        // Explicit gc call !
        Runtime.getRuntime().gc();
    }

    public explicitGCcall() {
        // Explicit gc call !
        System.gc();
    }

    public void doSomething() {
        // Explicit gc call !
        Runtime.getRuntime().gc();
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/DoNotCallGarbageCollectionExplicitly" />

DoNotExtendJavaLangThrowable

Since: PMD 6.0.0

Priority: Medium (3)

Extend Exception or RuntimeException instead of Throwable.

This rule is defined by the following XPath expression:

//ClassDeclaration/ExtendsList/ClassType
  [pmd-java:typeIsExactly('java.lang.Throwable')]

Example(s):

public class Foo extends Throwable { }

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/DoNotExtendJavaLangThrowable" />

DoNotHardCodeSDCard

Since: PMD 4.2.6

Priority: Medium (3)

Use Environment.getExternalStorageDirectory() instead of "/sdcard"

This rule is defined by the following XPath expression:

//StringLiteral[starts-with(@Image,'"/sdcard')]

Example(s):

public class MyActivity extends Activity {
    protected void foo() {
        String storageLocation = "/sdcard/mypackage";   // hard-coded, poor approach

       storageLocation = Environment.getExternalStorageDirectory() + "/mypackage"; // preferred approach
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/DoNotHardCodeSDCard" />

DoNotTerminateVM

Since: PMD 4.1

Priority: Medium (3)

Web applications should not call System.exit(), since only the web container or the application server should stop the JVM. Otherwise a web application would terminate all other applications running on the same application server.

This rule also checks for the equivalent calls Runtime.getRuntime().exit() and Runtime.getRuntime().halt().

This rule has been renamed from "DoNotCallSystemExit" in PMD 6.29.0.

This rule is defined by the following XPath expression:

//(MethodDeclaration[@MainMethod = false()] | Initializer)//MethodCall[
    pmd-java:matchesSig("java.lang.System#exit(int)")
    or pmd-java:matchesSig("java.lang.Runtime#exit(int)")
    or pmd-java:matchesSig("java.lang.Runtime#halt(int)")
]

Example(s):

public void bar() {
    System.exit(0);                 // never call this when running in an application server!
}
public void foo() {
    Runtime.getRuntime().exit(0);   // never stop the JVM manually, the container will do this.
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/DoNotTerminateVM" />

DoNotThrowExceptionInFinally

Since: PMD 4.2

Priority: Medium Low (4)

Throwing exceptions within a ‘finally’ block is confusing since they may mask other exceptions or code defects. Note: This is a PMD implementation of the Lint4j rule "A throw in a finally block"

This rule is defined by the following XPath expression:

//FinallyClause[descendant::ThrowStatement]

Example(s):

public class Foo {
    public void bar() {
        try {
            // Here do some stuff
        } catch( Exception e) {
            // Handling the issue
        } finally {
            // is this really a good idea ?
            throw new Exception();
        }
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/DoNotThrowExceptionInFinally" />

DontImportSun

Since: PMD 1.5

Priority: Medium Low (4)

Avoid importing anything from the ‘sun.*’ packages. These packages are not portable and are likely to change.

If you find yourself having to depend on Sun APIs, confine this dependency to as small a scope as possible, for instance by writing a stable wrapper class around the unstable API. You can then suppress this rule in the implementation of the wrapper.

This rule is defined by the following XPath expression:

//ImportDeclaration[starts-with(@ImportedName, 'sun.')]

Example(s):

import sun.misc.foo;
public class Foo {}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/DontImportSun" />

DontUseFloatTypeForLoopIndices

Since: PMD 4.3

Priority: Medium (3)

Don’t use floating point for loop indices. If you must use floating point, use double unless you’re certain that float provides enough precision and you have a compelling performance need (space or time).

This rule is defined by the following XPath expression:

//ForStatement/ForInit//VariableId[pmd-java:typeIs('float')]

Example(s):

public class Count {
  public static void main(String[] args) {
    final int START = 2000000000;
    int count = 0;
    for (float f = START; f < START + 50; f++)
      count++;
      //Prints 0 because (float) START == (float) (START + 50).
      System.out.println(count);
      //The termination test misbehaves due to floating point granularity.
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/DontUseFloatTypeForLoopIndices" />

EmptyCatchBlock

Since: PMD 0.1

Priority: Medium (3)

Empty Catch Block finds instances where an exception is caught, but nothing is done. In most circumstances, this swallows an exception which should either be acted on or reported.

This rule is defined by the following XPath expression:

//CatchClause[
  Block[
      count(*) = 0
      and ($allowCommentedBlocks = false() or @containsComment = false())
  ]
  and CatchParameter/VariableId[not(matches(@Name, $allowExceptionNameRegex))]
]

Example(s):

public void doSomething() {
    try {
        FileInputStream fis = new FileInputStream("/tmp/bugger");
    } catch (IOException ioe) {
        // not good
    }
}

This rule has the following properties:

Use this rule with the default properties by just referencing it:

<rule ref="category/java/errorprone.xml/EmptyCatchBlock" />

Use this rule and customize it:

<rule ref="category/java/errorprone.xml/EmptyCatchBlock">
    <properties>
        <property name="allowCommentedBlocks" value="false" />
        <property name="allowExceptionNameRegex" value="^(ignored|expected)$" />
    </properties>
</rule>

EmptyFinalizer

Since: PMD 1.5

Priority: Medium (3)

Empty finalize methods serve no purpose and should be removed. Note that Oracle has declared Object.finalize() as deprecated since JDK 9.

This rule is defined by the following XPath expression:

//MethodDeclaration[@Name='finalize'][@Arity = 0]
  /Block[not(*)]

Example(s):

public class Foo {
   protected void finalize() {}
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/EmptyFinalizer" />

EqualsNull

Since: PMD 1.9

Priority: High (1)

Tests for null should not use the equals() method. The ‘==’ operator should be used instead.

This rule is defined by the following XPath expression:

//MethodCall[@MethodName = "equals" and ArgumentList[count(*) = 1 and NullLiteral]]

Example(s):

String x = "foo";

if (x.equals(null)) {   // bad form
    doSomething();
}

if (x == null) {        // preferred
    doSomething();
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/EqualsNull" />

FinalizeDoesNotCallSuperFinalize

Since: PMD 1.5

Priority: Medium (3)

If the finalize() is implemented, its last action should be to call super.finalize. Note that Oracle has declared Object.finalize() as deprecated since JDK 9.

This rule is defined by the following XPath expression:

//MethodDeclaration[@Name = "finalize"][@Arity = 0]
   /Block/*[last()]
      [not(MethodCall[@MethodName = "finalize"]/SuperExpression)]
      [not(FinallyClause/Block/ExpressionStatement/
          MethodCall[@MethodName = "finalize"]/SuperExpression)]

Example(s):

protected void finalize() {
    something();
    // neglected to call super.finalize()
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/FinalizeDoesNotCallSuperFinalize" />

FinalizeOnlyCallsSuperFinalize

Since: PMD 1.5

Priority: Medium (3)

If the finalize() is implemented, it should do something besides just calling super.finalize(). Note that Oracle has declared Object.finalize() as deprecated since JDK 9.

This rule is defined by the following XPath expression:

//MethodDeclaration[@Name='finalize'][@Arity = 0]
   [Block[@Size=1]/ExpressionStatement/MethodCall[@MethodName = "finalize"][SuperExpression]]

Example(s):

protected void finalize() {
    super.finalize();
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/FinalizeOnlyCallsSuperFinalize" />

FinalizeOverloaded

Since: PMD 1.5

Priority: Medium (3)

Methods named finalize() should not have parameters. It is confusing and most likely an attempt to overload Object.finalize(). It will not be called by the VM.

Note that Oracle has declared Object.finalize() as deprecated since JDK 9.

This rule is defined by the following XPath expression:

//MethodDeclaration[@Name='finalize'][@Arity > 0]

Example(s):

public class Foo {
    // this is confusing and probably a bug
    protected void finalize(int a) {
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/FinalizeOverloaded" />

FinalizeShouldBeProtected

Since: PMD 1.1

Priority: Medium (3)

When overriding the finalize(), the new method should be set as protected. If made public, other classes may invoke it at inappropriate times.

Note that Oracle has declared Object.finalize() as deprecated since JDK 9.

This rule is defined by the following XPath expression:

//MethodDeclaration[@Visibility != "protected"][@Name='finalize'][@Arity = 0]

Example(s):

public void finalize() {
    // do something
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/FinalizeShouldBeProtected" />

IdempotentOperations

Since: PMD 2.0

Priority: Medium (3)

Avoid idempotent operations - they have no effect.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.IdempotentOperationsRule

Example(s):

public class Foo {
 public void bar() {
  int x = 2;
  x = x;
 }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/IdempotentOperations" />

ImplicitSwitchFallThrough

Since: PMD 3.0

Priority: Medium (3)

Switch statements without break or return statements for each case option may indicate problematic behaviour. Empty cases are ignored as these indicate an intentional fall-through.

You can ignore a violation by commenting // fallthrough before the case label which is reached by fallthrough, or with @SuppressWarnings("fallthrough").

This rule has been renamed from "MissingBreakInSwitch" in PMD 6.37.0.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.ImplicitSwitchFallThroughRule

Example(s):

public void bar(int status) {
    switch(status) {
      case CANCELLED:
        doCancelled();
        // break; hm, should this be commented out?
      case NEW:
        doNew();
        // is this really a fall-through?
        // what happens if you add another case after this one?
      case REMOVED:
        doRemoved();
        // fallthrough - this comment just clarifies that you want a fallthrough
      case OTHER: // empty case - this is interpreted as an intentional fall-through
      case ERROR:
        doErrorHandling();
        break;
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/ImplicitSwitchFallThrough" />

InstantiationToGetClass

Since: PMD 2.0

Priority: Medium Low (4)

Avoid instantiating an object just to call getClass() on it; use the .class public member instead.

This rule is defined by the following XPath expression:

//MethodCall
 [@MethodName='getClass']
 [ConstructorCall]

Example(s):

// replace this
Class c = new String().getClass();

// with this:
Class c = String.class;

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/InstantiationToGetClass" />

InvalidLogMessageFormat

Since: PMD 5.5.0

Priority: Low (5)

Check for messages in slf4j and log4j2 (since 6.19.0) loggers with non matching number of arguments and placeholders.

Since 6.32.0 in addition to parameterized message placeholders ({}) also format specifiers of string formatted messages are supported (%s).

This rule has been renamed from "InvalidSlf4jMessageFormat" in PMD 6.19.0.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.InvalidLogMessageFormatRule

Example(s):

LOGGER.error("forget the arg {}");
LOGGER.error("forget the arg %s");
LOGGER.error("too many args {}", "arg1", "arg2");
LOGGER.error("param {}", "arg1", new IllegalStateException("arg")); //The exception is shown separately, so is correct.

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/InvalidLogMessageFormat" />

JumbledIncrementer

Since: PMD 1.0

Priority: Medium (3)

Avoid jumbled loop incrementers - it’s usually a mistake, and is confusing even if intentional.

This rule is defined by the following XPath expression:

//ForStatement
    [not(ForInit) or ForInit//VariableId/@Name != ForUpdate//VariableAccess/@Name]
    [ForUpdate//VariableAccess[@AccessType = 'WRITE']/@Name
     =
     ancestor::ForStatement/ForInit//VariableId/@Name
    ]

Example(s):

public class JumbledIncrementerRule1 {
    public void foo() {
        for (int i = 0; i < 10; i++) {          // only references 'i'
            for (int k = 0; k < 20; i++) {      // references both 'i' and 'k'
                System.out.println("Hello");
            }
        }
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/JumbledIncrementer" />

JUnitSpelling

Since: PMD 1.0

Priority: Medium (3)

In JUnit 3, the setUp method is used to set up all data entities required in running tests. The tearDown method is used to clean up all data entities required in running tests. You should not misspell method name if you want your test to set up and clean up everything correctly.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.JUnitSpellingRule

Example(s):

import junit.framework.*;

public class Foo extends TestCase {
    public void setup() {}    // oops, should be setUp
    public void TearDown() {} // oops, should be tearDown
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/JUnitSpelling" />

JUnitStaticSuite

Since: PMD 1.0

Priority: Medium (3)

The suite() method in a JUnit test needs to be both public and static.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.JUnitStaticSuiteRule

Example(s):

import junit.framework.*;

public class Foo extends TestCase {
    public void suite() {}         // oops, should be static
}

import junit.framework.*;

public class Foo extends TestCase {
    private static void suite() {} // oops, should be public
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/JUnitStaticSuite" />

MethodWithSameNameAsEnclosingClass

Since: PMD 1.5

Priority: Medium (3)

A method should not have the same name as its containing class. This would be confusing as it would look like a constructor.

This rule is defined by the following XPath expression:

//MethodDeclaration[@Name = ancestor::ClassDeclaration/@SimpleName]

Example(s):

public class MyClass {

    public MyClass() {}         // this is OK because it is a constructor

    public void MyClass() {}    // this is bad because it is a method
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/MethodWithSameNameAsEnclosingClass" />

MisplacedNullCheck

Since: PMD 3.5

Priority: Medium (3)

The null check here is misplaced. If the variable is null a NullPointerException will be thrown. Either the check is useless (the variable will never be null) or it is incorrect.

This rule is defined by the following XPath expression:

//InfixExpression[@Operator = '&&']
    /InfixExpression[@Operator = '!=']
        (: one side is null :)
        [NullLiteral]
        (: other side checks for the variable used somewhere in the first child of conditional and expression :)
        [VariableAccess]
        [some $var in preceding-sibling::*//VariableAccess
            [parent::MethodCall or parent::FieldAccess]
            [not(ancestor::InfixExpression[@Operator = '||'])]
            /@Name
            satisfies $var = VariableAccess/@Name
        ]
    /VariableAccess
|
//InfixExpression[@Operator = '||']
    /InfixExpression[@Operator = '==']
        (: one side is null :)
        [NullLiteral]
        (: other side checks for the variable used somewhere in the first child of conditional or expression :)
        [VariableAccess]
        [some $var in preceding-sibling::*//VariableAccess
            [parent::MethodCall or parent::FieldAccess]
            [not(ancestor::InfixExpression[@Operator = '&&'])]
            /@Name
            satisfies $var = VariableAccess/@Name
        ]
    /VariableAccess

Example(s):

public class Foo {
    void bar() {
        if (a.equals(baz) && a != null) {} // a could be null, misplaced null check

        if (a != null && a.equals(baz)) {} // correct null check
    }
}

public class Foo {
    void bar() {
        if (a.equals(baz) || a == null) {} // a could be null, misplaced null check

        if (a == null || a.equals(baz)) {} // correct null check
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/MisplacedNullCheck" />

MissingSerialVersionUID

Since: PMD 3.0

Priority: Medium (3)

Serializable classes should provide a serialVersionUID field. The serialVersionUID field is also needed for abstract base classes. Each individual class in the inheritance chain needs an own serialVersionUID field. See also Should an abstract class have a serialVersionUID.

This rule is defined by the following XPath expression:

//ClassDeclaration
    [@Interface = false()]
    [count(ClassBody/FieldDeclaration/VariableDeclarator/VariableId[@Name='serialVersionUID']) = 0]
    [(ImplementsList | ExtendsList)/ClassType[pmd-java:typeIs('java.io.Serializable')]]

Example(s):

public class Foo implements java.io.Serializable {
    String name;
    // Define serialization id to avoid serialization related bugs
    // i.e., public static final long serialVersionUID = 4328743;
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/MissingSerialVersionUID" />

MissingStaticMethodInNonInstantiatableClass

Since: PMD 3.0

Priority: Medium (3)

A class that has private constructors and does not have any static methods or fields cannot be used.

When one of the private constructors is annotated with one of the annotations, then the class is not considered non-instantiatable anymore and no violation will be reported. See the property annotations.

This rule is defined by the following XPath expression:

let $topLevelClass := /*/ClassDeclaration return
let $isLombokUtility := exists($topLevelClass[pmd-java:hasAnnotation('lombok.experimental.UtilityClass')]) return
$topLevelClass[
        (: non-instantiable :)
        $isLombokUtility or
        (
            (: no lombok produced constructors :)
            not(pmd-java:hasAnnotation('lombok.NoArgsConstructor') or
                pmd-java:hasAnnotation('lombok.RequiredArgsConstructor') or
                pmd-java:hasAnnotation('lombok.AllArgsConstructor') or
                pmd-java:hasAnnotation('lombok.Builder')) and
            (: or has non-default constructors … :)
            ClassBody/ConstructorDeclaration and
                (: … but only private … :)
                not(ClassBody/ConstructorDeclaration[@Visibility != "private"]) and
                (: … and none annotated … :)
                (every $x in $annotations satisfies
                      not(ClassBody/ConstructorDeclaration/ModifierList/Annotation[pmd-java:typeIs($x)]))
        )
    ]
    [
        (: With no visible static methods … :)
        not(ClassBody/MethodDeclaration[($isLombokUtility or pmd-java:modifiers() = "static") and @Visibility != "private"]) and
        (: … nor fields … :)
        not(ClassBody/FieldDeclaration[($isLombokUtility or pmd-java:modifiers() = "static") and @Visibility != "private"]) and
        (: … no nested classes, that are non-private and static … :)
        not(ClassBody/ClassDeclaration
            [pmd-java:modifiers() = "static" and @Visibility != "private"]
            (: … and a non-private method returning the outer class type … :)
            [(ClassBody/MethodDeclaration
                [@Visibility != "private"]
                [descendant::ReturnStatement/*[1][pmd-java:typeIs(ancestor::ClassDeclaration[@Nested = false()]/@BinaryName)]]
            ) or (
                (: … or the inner class extends the outer class :)
                ExtendsList/ClassType[@SimpleName = ancestor::ClassDeclaration[@Nested = false()]/@SimpleName]
            )]
    )]

Example(s):

// This class is unusable, since it cannot be
// instantiated (private constructor),
// and no static method can be called.

public class Foo {
  private Foo() {}
  void foo() {}
}

This rule has the following properties:

Use this rule with the default properties by just referencing it:

<rule ref="category/java/errorprone.xml/MissingStaticMethodInNonInstantiatableClass" />

Use this rule and customize it:

<rule ref="category/java/errorprone.xml/MissingStaticMethodInNonInstantiatableClass">
    <properties>
        <property name="annotations" value="org.springframework.beans.factory.annotation.Autowired,javax.inject.Inject,com.google.inject.Inject,lombok.Builder" />
    </properties>
</rule>

MoreThanOneLogger

Since: PMD 2.0

Priority: Medium High (2)

Normally only one logger is used in each class. This rule supports slf4j, log4j, Java Util Logging and log4j2 (since 6.19.0).

This rule is defined by the following XPath expression:

//ClassDeclaration[
  count(
    ClassBody/FieldDeclaration/ClassType[
      pmd-java:typeIs("org.apache.log4j.Logger") or
      pmd-java:typeIs("org.apache.logging.log4j.Logger") or
      pmd-java:typeIs("java.util.logging.Logger") or
      pmd-java:typeIs("org.slf4j.Logger")
    ]
  ) > 1
]

Example(s):

public class Foo {
    Logger log = Logger.getLogger(Foo.class.getName());
    // It is very rare to see two loggers on a class, normally
    // log information is multiplexed by levels
    Logger log2= Logger.getLogger(Foo.class.getName());
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/MoreThanOneLogger" />

NonCaseLabelInSwitch

Since: PMD 1.5

Priority: Medium (3)

A non-case label (e.g. a named break/continue label) was present in a switch statement or switch expression. This is legal, but confusing. It is easy to mix up the case labels and the non-case labels.

Note: This rule was renamed from NonCaseLabelInSwitchStatement with PMD 7.7.0.

This rule is defined by the following XPath expression:

//(SwitchStatement|SwitchExpression)//LabeledStatement

Example(s):

public class Foo {
  void bar(int a) {
   switch (a) {
     case 1:
       // do something
     mylabel: // this is legal, but confusing!
       break;
     default:
       break;
    }
  }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/NonCaseLabelInSwitch" />

NonCaseLabelInSwitchStatement

Deprecated

This rule has been renamed. Use instead: NonCaseLabelInSwitch

Deprecated

Since: PMD 1.5

Priority: Medium (3)

A non-case label (e.g. a named break/continue label) was present in a switch statement or switch expression. This is legal, but confusing. It is easy to mix up the case labels and the non-case labels.

Note: This rule was renamed from NonCaseLabelInSwitchStatement with PMD 7.7.0.

This rule is defined by the following XPath expression:

//(SwitchStatement|SwitchExpression)//LabeledStatement

Example(s):

public class Foo {
  void bar(int a) {
   switch (a) {
     case 1:
       // do something
     mylabel: // this is legal, but confusing!
       break;
     default:
       break;
    }
  }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/NonCaseLabelInSwitchStatement" />

NonSerializableClass

Since: PMD 1.1

Priority: Medium (3)

If a class is marked as Serializable, then all fields need to be serializable as well. In order to exclude a field, it can be marked as transient. Static fields are not considered.

This rule reports all fields, that are not serializable.

If a class implements the methods to perform manual serialization (writeObject, readObject) or uses a replacement object (writeReplace, readResolve) then this class is ignored.

Note: This rule has been revamped with PMD 6.52.0. It was previously called "BeanMembersShouldSerialize". The property prefix has been deprecated, since in a serializable class all fields have to be serializable regardless of the name.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.NonSerializableClassRule

Example(s):

class Buzz implements java.io.Serializable {
    private static final long serialVersionUID = 1L;

    private transient int someFoo;          // good, it's transient
    private static int otherFoo;            // also OK, it's static
    private java.io.FileInputStream stream; // bad - FileInputStream is not serializable

    public void setStream(FileInputStream stream) {
        this.stream = stream;
    }

    public int getSomeFoo() {
          return this.someFoo;
    }
}

This rule has the following properties:

Use this rule with the default properties by just referencing it:

<rule ref="category/java/errorprone.xml/NonSerializableClass" />

Use this rule and customize it:

<rule ref="category/java/errorprone.xml/NonSerializableClass">
    <properties>
        <property name="checkAbstractTypes" value="false" />
    </properties>
</rule>

NonStaticInitializer

Since: PMD 1.5

Priority: Medium (3)

A non-static initializer block will be called any time a constructor is invoked (just prior to invoking the constructor). While this is a valid language construct, it is rarely used and is confusing.

This rule is defined by the following XPath expression:

//Initializer[@Static=false()][not(ancestor::*[3][self::ConstructorCall or self::EnumConstant])]

Example(s):

public class MyClass {
  // this block gets run before any call to a constructor
  {
    System.out.println("I am about to construct myself");
  }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/NonStaticInitializer" />

NullAssignment

Since: PMD 1.02

Priority: Medium (3)

Assigning a "null" to a variable (outside of its declaration) is usually bad form. Sometimes, this type of assignment is an indication that the programmer doesn’t completely understand what is going on in the code.

NOTE: This sort of assignment may used in some cases to dereference objects and encourage garbage collection.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.NullAssignmentRule

Example(s):

public void bar() {
  Object x = null; // this is OK
  x = new Object();
     // big, complex piece of code here
  x = null; // this is not required
     // big, complex piece of code here
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/NullAssignment" />

OverrideBothEqualsAndHashcode

Since: PMD 0.4

Priority: Medium (3)

Override both public boolean Object.equals(Object other), and public int Object.hashCode(), or override neither. Even if you are inheriting a hashCode() from a parent class, consider implementing hashCode and explicitly delegating to your superclass.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.OverrideBothEqualsAndHashcodeRule

Example(s):

public class Bar {        // poor, missing a hashcode() method
    public boolean equals(Object o) {
      // do some comparison
    }
}

public class Baz {        // poor, missing an equals() method
    public int hashCode() {
      // return some hash value
    }
}

public class Foo {        // perfect, both methods provided
    public boolean equals(Object other) {
      // do some comparison
    }
    public int hashCode() {
      // return some hash value
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/OverrideBothEqualsAndHashcode" />

ProperCloneImplementation

Since: PMD 1.4

Priority: Medium High (2)

Object clone() should be implemented with super.clone().

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.ProperCloneImplementationRule

Example(s):

class Foo{
    public Object clone(){
        return new Foo(); // This is bad
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/ProperCloneImplementation" />

ProperLogger

Since: PMD 3.3

Priority: Medium (3)

A logger should normally be defined private static final and be associated with the correct class. private final Log log; is also allowed for rare cases where loggers need to be passed around, with the restriction that the logger needs to be passed into the constructor.

This rule is defined by the following XPath expression:

//FieldDeclaration
    [ClassType[pmd-java:typeIs($loggerClass)]]
    [
        (: check modifiers :)
        (not(pmd-java:modifiers() = 'private') or not(pmd-java:modifiers() = 'final'))
        (: check logger name :)
        or (pmd-java:modifiers() = 'static' and VariableDeclarator/VariableId/@Name != $staticLoggerName)
        or (not(pmd-java:modifiers() = 'static') and VariableDeclarator/VariableId/@Name != $loggerName)
        (: check logger argument type matches class or enum name :)
        or .//ArgumentList/ClassLiteral/ClassType/@SimpleName != ancestor::ClassDeclaration/@SimpleName
        or .//ArgumentList/ClassLiteral/ClassType/@SimpleName != ancestor::EnumDeclaration/@SimpleName

        (: special case - final logger initialized inside constructor :)
        or (VariableDeclarator/@Initializer = false()
            and not(pmd-java:modifiers() = 'static')
            and not(ancestor::ClassBody/ConstructorDeclaration
                //AssignmentExpression[@Operator = '=']
                    [FieldAccess[1]/@Name = $loggerName or VariableAccess[1]/@Name = $loggerName]
                    [*[2][@Name = ancestor::ConstructorDeclaration//FormalParameter/VariableId/@Name]])
        )
    ]

Example(s):

public class Foo {

    private static final Log LOG = LogFactory.getLog(Foo.class);    // proper way

    protected Log LOG = LogFactory.getLog(Testclass.class);         // wrong approach
}

This rule has the following properties:

Use this rule with the default properties by just referencing it:

<rule ref="category/java/errorprone.xml/ProperLogger" />

Use this rule and customize it:

<rule ref="category/java/errorprone.xml/ProperLogger">
    <properties>
        <property name="staticLoggerName" value="LOG" />
        <property name="loggerName" value="log" />
        <property name="loggerClass" value="org.apache.commons.logging.Log" />
    </properties>
</rule>

ReturnEmptyCollectionRatherThanNull

Since: PMD 6.37.0

Priority: High (1)

For any method that returns an collection (such as an array, Collection or Map), it is better to return an empty one rather than a null reference. This removes the need for null checking all results and avoids inadvertent NullPointerExceptions.

See Effective Java, 3rd Edition, Item 54: Return empty collections or arrays instead of null

This rule is defined by the following XPath expression:

//ReturnStatement/NullLiteral
[ancestor::MethodDeclaration[1]
    [ArrayType
     or ClassType[pmd-java:typeIs('java.util.Collection')
        or pmd-java:typeIs('java.util.Map')]]
]
[not(./ancestor::LambdaExpression)]

Example(s):

public class Example {
    // Not a good idea...
    public int[] badBehavior() {
        // ...
        return null;
    }

    // Good behavior
    public String[] bonnePratique() {
        //...
        return new String[0];
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/ReturnEmptyCollectionRatherThanNull" />

ReturnFromFinallyBlock

Since: PMD 1.05

Priority: Medium (3)

Avoid returning from a finally block, this can discard exceptions.

This rule is defined by the following XPath expression:

//FinallyClause//ReturnStatement except //FinallyClause//(MethodDeclaration|LambdaExpression)//ReturnStatement

Example(s):

public class Bar {
    public String foo() {
        try {
            throw new Exception( "My Exception" );
        } catch (Exception e) {
            throw e;
        } finally {
            return "A. O. K."; // return not recommended here
        }
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/ReturnFromFinallyBlock" />

SimpleDateFormatNeedsLocale

Since: PMD 2.0

Priority: Medium (3)

Be sure to specify a Locale when creating SimpleDateFormat instances to ensure that locale-appropriate formatting is used.

This rule is defined by the following XPath expression:

//ConstructorCall
    [pmd-java:typeIs('java.text.SimpleDateFormat')]
    [ArgumentList/@Size = 1]

Example(s):

public class Foo {
  // Should specify Locale.US (or whatever)
  private SimpleDateFormat sdf = new SimpleDateFormat("pattern");
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/SimpleDateFormatNeedsLocale" />

SingleMethodSingleton

Since: PMD 5.4

Priority: Medium High (2)

Some classes contain overloaded getInstance. The problem with overloaded getInstance methods is that the instance created using the overloaded method is not cached and so, for each call and new objects will be created for every invocation.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.SingleMethodSingletonRule

Example(s):

public class Singleton {

    private static Singleton singleton = new Singleton( );

    private Singleton(){ }

    public static Singleton getInstance( ) {
        return singleton;
    }

    public static Singleton getInstance(Object obj){
        Singleton singleton = (Singleton) obj;
        return singleton;           //violation
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/SingleMethodSingleton" />

SingletonClassReturningNewInstance

Since: PMD 5.4

Priority: Medium High (2)

A singleton class should only ever have one instance. Failure to check whether an instance has already been created may result in multiple instances being created.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.java.rule.errorprone.SingletonClassReturningNewInstanceRule

Example(s):

class Singleton {
    private static Singleton instance = null;
    public static Singleton getInstance() {
        synchronized(Singleton.class) {
            return new Singleton(); // this should be assigned to the field
        }
    }
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/SingletonClassReturningNewInstance" />

StaticEJBFieldShouldBeFinal

Since: PMD 4.1

Priority: Medium (3)

According to the J2EE specification, an EJB should not have any static fields with write access. However, static read-only fields are allowed. This ensures proper behavior especially when instances are distributed by the container on several JREs.

This rule is defined by the following XPath expression:

//ClassDeclaration[ImplementsList/ClassType[
        pmd-java:typeIs('javax.ejb.SessionBean')
     or pmd-java:typeIs('javax.ejb.EJBHome')
     or pmd-java:typeIs('javax.ejb.EJBLocalObject')
     or pmd-java:typeIs('javax.ejb.EJBLocalHome')
     or pmd-java:typeIs('javax.ejb.EJBObject')
    ]]
    /ClassBody/FieldDeclaration
        [pmd-java:modifiers() = 'static']
        [not(pmd-java:modifiers() = 'final')]

Example(s):

public class SomeEJB extends EJBObject implements EJBLocalHome {

    private static int CountA;          // poor, field can be edited

    private static final int CountB;    // preferred, read-only access
}

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/StaticEJBFieldShouldBeFinal" />

StringBufferInstantiationWithChar

Since: PMD 3.9

Priority: Medium Low (4)

Individual character values provided as initialization arguments will be converted into integers. This can lead to internal buffer sizes that are larger than expected. Some examples:

new StringBuffer()      //  16
new StringBuffer(6)     //  6
new StringBuffer("hello world")  // 11 + 16 = 27
new StringBuffer('A')   //  chr(A) = 65
new StringBuffer("A")   //  1 + 16 = 17

new StringBuilder()     //  16
new StringBuilder(6)    //  6
new StringBuilder("hello world")  // 11 + 16 = 27
new StringBuilder('C')   //  chr(C) = 67
new StringBuilder("A")   //  1 + 16 = 17

This rule is defined by the following XPath expression:

//ConstructorCall[ArgumentList/*[pmd-java:typeIsExactly('char')]]
    [pmd-java:matchesSig('java.lang.StringBuilder#new(int)')
     or pmd-java:matchesSig('java.lang.StringBuffer#new(int)')]

Example(s):

// misleading instantiation, these buffers
// are actually sized to 99 characters long
StringBuffer  sb1 = new StringBuffer('c');
StringBuilder sb2 = new StringBuilder('c');

// in these forms, just single characters are allocated
StringBuffer  sb3 = new StringBuffer("c");
StringBuilder sb4 = new StringBuilder("c");

Use this rule by referencing it:

<rule ref="category/java/errorprone.xml/StringBufferInstantiationWithChar" />

SuspiciousEqualsMethodName