# Error Prone

Rules to detect constructs that are either broken, extremely confusing or prone to runtime errors.
Table of Contents

## 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:

Name | Default Value | Description
--- | --- | ---
allowIf | false | Allow assignment within the conditional expression of an if statement
allowFor | false | Allow assignment within the conditional expression of a for statement
allowWhile | false | Allow assignment within the conditional expression of a while statement
allowIncrementDecrement | false | Allow increment or decrement operators in any context
allowDoWhile | false | Allow assignment within the conditional expression of a do-while statement
allowSwitch | false | Allow assignment within the conditional expression of a switch statement

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" />
            <property name="allowDoWhile" value="false" />
            <property name="allowSwitch" 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:

Name | Default Value | Description
--- | --- | ---
checkBreakLoopTypes | for , do , while | List of loop types in which break statements will be checked Zero or more of: `do`, `for`, `while`
checkContinueLoopTypes | for , do , while | List of loop types in which continue statements will be checked Zero or more of: `do`, `for`, `while`
checkReturnLoopTypes | for , do , while | List of loop types in which return statements will be checked Zero or more of: `do`, `for`, `while`

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" />

## AvoidCatchingGenericException

Since: PMD 4.2.6

Priority: Medium (3)

Avoid catching generic exceptions in try-catch blocks. Catching overly broad exception types makes it difficult to understand what can actually go wrong in your code and can hide real problems.

Why these exceptions should not be caught:

- Exception: This is the base class for all checked exceptions. Catching it means you’re handling all possible checked exceptions the same way, which is rarely appropriate and makes error handling less precise.

- RuntimeException: These represent programming errors (like logic bugs) that should typically be fixed in code rather than caught and handled. Catching them can hide bugs that should be addressed during development.

- NullPointerException: This usually indicates a programming error (accessing null references). Rather than catching it, code should be written to avoid null pointer dereferences through null checks or defensive programming.

- Throwable: This is the superclass of all errors and exceptions. Catching it means you’re trying to handle both recoverable exceptions and serious errors (like OutOfMemoryError) the same way, which is dangerous.

- Error: These represent serious problems that applications should not try to handle (like OutOfMemoryError, StackOverflowError). Catching Error can prevent the JVM from properly terminating when it encounters unrecoverable situations.

Better approaches:

- Catch specific exception types that you can meaningfully handle
- Use multiple catch blocks for different exception types that require different handling
- Consider using defensive programming techniques to prevent exceptions rather than catching them

This rule is defined by the following XPath expression:

    //CatchParameter//ClassType[
        some $type in $typesThatShouldNotBeCaught
        satisfies pmd-java:typeIsExactly($type)]

Example(s):

    public class PrimitiveType {
        public void downCastPrimitiveType(int i) {
            try {
                System.out.println(" i [" + i + "]");
            } catch(NullPointerException e) {
                e.printStackTrace();
            } catch(RuntimeException e) {
                e.printStackTrace();
            } catch(Exception e) {
                e.printStackTrace();
            }
        }
    }

This rule has the following properties:

Name | Default Value | Description
--- | --- | ---
typesThatShouldNotBeCaught | java.lang.NullPointerException , java.lang.Exception , java.lang.RuntimeException , java.lang.Throwable , java.lang.Error | List of canonical type names that should trigger a violation if used in a catch clause.

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

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

Use this rule and customize it:

    <rule ref="category/java/errorprone.xml/AvoidCatchingGenericException">
        <properties>
            <property name="typesThatShouldNotBeCaught" value="java.lang.NullPointerException,java.lang.Exception,java.lang.RuntimeException,java.lang.Throwable,java.lang.Error" />
        </properties>
    </rule>

## AvoidCatchingNPE

Deprecated

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.

Deprecated: This rule is deprecated since PMD 7.18.0 and will be removed with PMD 8.0.0. This rule has been subsumed by `AvoidCatchingGenericException`, which is now configurable as to which exceptions cause a violation.

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

Deprecated

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.

Deprecated: This rule is deprecated since PMD 7.18.0 and will be removed with PMD 8.0.0. This rule has been subsumed by `AvoidCatchingGenericException`, which is now configurable as to which exceptions cause a violation.

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:

Name | Default Value | Description
--- | --- | ---
maxDuplicateLiterals | 4 | Max duplicate literals
minimumLength | 3 | Minimum string length to check
skipAnnotations | false | Skip literals within annotations
exceptionList |  | List of literals to ignore. A literal is ignored if its image can be found in this list. Components of this list should not be surrounded by double quotes.

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]
                /following-sibling::TypeExpression/*

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:

Name | Default Value | Description
--- | --- | ---
ignoreMagicNumbers | -1,0 | Comma-separated list of magic numbers, that should be ignored
ignoreExpressions | true | If true, only literals in simple if conditions are considered. Otherwise literals in expressions are checked, too.

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

Deprecated

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.

Deprecated: This rule is deprecated since PMD 7.17.0 and will be removed with PMD 8.0.0. This rule has been replaced by `UselessPureMethodCall`.

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 that start with zero are interpreted as octal (base-8) values in Java, which can lead to unexpected behavior and bugs. Most developers expect decimal (base-10) interpretation, making octal literals a common source of confusion and errors. For example, 012 equals 10 in decimal, not 12 as might be expected. This rule helps prevent such mistakes by flagging integer literals that could be misinterpreted as decimal values. Use decimal literals without leading zeros, or use explicit prefixes like 0x for hexadecimal or 0b for binary values to make the intended base clear.

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

Example(s):

    // Bad: These look like decimal but are actually octal
    int timeout = 060;     // Actually 48 in decimal, not 60!
    int count = 012;       // Actually 10 in decimal, not 12!

    // Good: Use decimal literals
    int timeout = 60;      // Clear decimal value
    int count = 12;        // Clear decimal value

    // Good: Use explicit prefixes for other bases
    int hexValue = 0xFF;   // Clearly hexadecimal
    int binaryValue = 0b1010; // Clearly binary (Java 7+)

This rule has the following properties:

Name | Default Value | Description
--- | --- | ---
strict | false | Detect violations between 00 and 07

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.

The property `allowedResourceMethodPatterns` can be used to specify method invocation patterns that return resources which are managed externally and don’t need to be closed by the caller. This is useful for servlet-related streams like `HttpServletRequest.getReader()` or `HttpServletResponse.getWriter()`, which are managed by the servlet container. The patterns use InvocationMatcher syntax (e.g., `javax.servlet.ServletRequest#getReader()`).

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:

Name | Default Value | Description
--- | --- | ---
closeTargets |  | Methods which may close this resource
types | java.lang.AutoCloseable , java.sql.Connection , java.sql.Statement , java.sql.ResultSet | Affected types
closeAsDefaultTarget | true | Consider ‘close’ as a target by default
allowedResourceTypes | 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 | Exact class names that do not need to be closed
allowedResourceMethodPatterns | javax.servlet.ServletRequest#getReader() , javax.servlet.ServletResponse#getWriter() , javax.servlet.ServletResponse#getOutputStream() , javax.servlet.http.HttpServletRequest#getReader() , javax.servlet.http.HttpServletResponse#getWriter() , javax.servlet.http.HttpServletResponse#getOutputStream() , jakarta.servlet.ServletRequest#getReader() , jakarta.servlet.ServletResponse#getWriter() , jakarta.servlet.ServletResponse#getOutputStream() , jakarta.servlet.http.HttpServletRequest#getReader() , jakarta.servlet.http.HttpServletResponse#getWriter() , jakarta.servlet.http.HttpServletResponse#getOutputStream() | Method invocation patterns that return resources managed externally (InvocationMatcher syntax)
closeNotInFinally | false | Detect if ‘close’ (or other closeTargets) is called outside of a finally-block

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="allowedResourceMethodPatterns" value="javax.servlet.ServletRequest#getReader(),javax.servlet.ServletResponse#getWriter(),javax.servlet.ServletResponse#getOutputStream(),javax.servlet.http.HttpServletRequest#getReader(),javax.servlet.http.HttpServletResponse#getWriter(),javax.servlet.http.HttpServletResponse#getOutputStream(),jakarta.servlet.ServletRequest#getReader(),jakarta.servlet.ServletResponse#getWriter(),jakarta.servlet.ServletResponse#getOutputStream(),jakarta.servlet.http.HttpServletRequest#getReader(),jakarta.servlet.http.HttpServletResponse#getWriter(),jakarta.servlet.http.HttpServletResponse#getOutputStream()" />
            <property name="closeNotInFinally" value="false" />
        </properties>
    </rule>

## CollectionTypeMismatch

Since: PMD 7.17.0

Priority: Medium (3)

Detects method calls on collections where the passed object cannot possibly be in the collection due to type mismatch. This helps catch potential programming errors where incompatible types are used with collection methods like contains(), remove(), indexOf(), etc.

Methods checked include:

- Collection: contains(), remove(), removeAll(), retainAll(), containsAll()
- List: indexOf(), lastIndexOf()
- Map: containsKey(), containsValue(), get(), getOrDefault(), remove()
- Deque: removeFirstOccurrence(), removeLastOccurrence()
- Hashtable: contains() (legacy method that checks values)
- ConcurrentHashMap: contains() (legacy method that checks values)

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

Example(s):

    List<Integer> numbers = Arrays.asList(1, 2, 3);
    numbers.remove("string"); // violation: String cannot be in Integer list

    Map<String, Integer> map = new HashMap<>();
    map.get(42); // violation: Integer key cannot be in String-keyed map

    Set<String> names = new HashSet<>();
    names.contains(123); // violation: Integer cannot be in String set

Use this rule by referencing it:

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

## 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:

Name | Default Value | Description
--- | --- | ---
typesThatCompareByReference | java.lang.Enum , java.lang.Class | List of canonical type names for which reference comparison is allowed.

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

Deprecated

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.

Deprecated: This rule is deprecated since PMD 7.21.0 and will be removed with PMD 8.0.0. This rule has been replaced by `UnsupportedJdkApiUsage`.

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')]
        or ForUpdate//VariableAccess[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:

Name | Default Value | Description
--- | --- | ---
allowCommentedBlocks | false | Empty blocks containing comments will be skipped
allowExceptionNameRegex | ^(ignored|expected)$ | Empty blocks catching exceptions with names matching this regular expression will be skipped

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:

    //ClassDeclaration
      /ClassBody
        /MethodDeclaration[@Name = "finalize"][@Arity = 0][@Final = false() or ancestor::ClassDeclaration[@Final = true()]]
          /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" />

## IdenticalConditionalBranches

Since: PMD 7.18.0

Priority: Medium (3)

Conditional statement that does the same thing when the condition is true and false is either incorrect (one of the branches should be changed) or redundant (can be replaced by one of its branches).

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

Example(s):

    class Test {
        int method1() {
            if (Math.random() > 0.5) {
                return 1;
            } else {
                return 1;
            }
        }
        int method2() {
            return Math.random() > 0.5 ? 1 : 1;
        }
    }

Use this rule by referencing it:

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

## 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:

Name | Default Value | Description
--- | --- | ---
annotations | org.springframework.beans.factory.annotation.Autowired , javax.inject.Inject , com.google.inject.Inject , lombok.Builder | If a constructor is annotated with one of these annotations, then the class is ignored.

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:

Name | Default Value | Description
--- | --- | ---
checkAbstractTypes | false | Enable to verify fields with abstract types like abstract classes, interfaces, generic types or java.lang.Object. Enabling this might lead to more false positives, since the concrete runtime type can actually be serializable.

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.

Not overriding both methods could violate the contract between `equals()` and `hashCode()`. Most importantly, if two instances are equal, then they must have the same hash code. Using such invalid instances in hash-based collections like `HashSet` or `HashMap` could lead to duplicated or missing entries.

This rule does not consider types that implement `Comparable`. There is a separate rule `OverrideBothEqualsAndHashCodeOnComparable` for this.

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" />

## OverrideBothEqualsAndHashCodeOnComparable

Since: PMD 7.17.0

Priority: Medium (3)

Classes that implement `Comparable` should override both `equals()` and `hashCode()` if instances of these classes are used in collections. This is to ensure that the class’s natural ordering is consistent with `equals()`. Failing to do so can lead to unexpected behavior in sets which then do not conform to the `Set` interface. While the `Set` interface relies on `equals()` to determine object equality, sorted sets like `TreeSet` use `compareTo()` instead. The same issue can arise when such objects are used as keys in sorted maps.

Note 1: This rule is related to `OverrideBothEqualsAndHashcode`. It will report missing `equals()` and/or `hashCode()` methods for classes only that implement `Comparable`.

Note 2: This rule reports records only, if either `equals()` or `hashCode()` have been overridden, but not both. If a record uses the generated equals/hashCode methods, then the `compareTo()` implementation is only consistent with `equals()` if all record components are considered.

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

Example(s):

    public class Bar implements Comparable<Bar> {  // poor - missing equals() and hashCode()
        public int compareTo(Bar other) {
            // some comparison
        }
    }

    public class Baz implements Comparable<Baz> {  // poor - missing hashCode()
        public int compareTo(Baz other) {
            // some comparison
        }
        public boolean equals(Object o) {
            if (o == null || getClass() != o.getClass()) {
                return false;
            }
            return compareTo((Baz) o) == 0;
        }
    }

    public class Foo implements Comparable<Foo> {  // correct
        public int compareTo(Foo other) {
            // some comparison
        }
        public boolean equals(Object o) {
            if (o == null || getClass() != o.getClass()) {
                return false;
            }
            return compareTo((Foo) o) == 0;
        }
        public int hashCode() {
            // return hash code
        }
    }

Use this rule by referencing it:

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

## 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:

Name | Default Value | Description
--- | --- | ---
staticLoggerName | LOG | Name of the static Logger variable
loggerName | log | Name of the Logger instance variable
loggerClass | org.apache.commons.logging.Log | Class name of the logger

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>

## ReplaceJavaUtilCalendar

Since: PMD 7.16.0

Priority: Medium (3)

Minimum Language Version: Java 1.8

The legacy `java.util.Calendar` API is error-prone, mutable, and not thread-safe. It has confusing month indexing (January = 0), inconsistent field semantics, and verbose usage patterns. The modern `java.time API` (introduced in Java 8) provides immutable, thread-safe alternatives with clear, intuitive methods.

Use `LocalDate` (for date-only operations), `LocalDateTime` (for date and time), or `ZonedDateTime` (when timezone is important) from `java.time` package instead.

Note: Since JPA 3.2 (Jakarta Persistence) usage of `java.util.Date` and `java.util.Calendar` and others is deprecated there as well in favour of `java.time` API.

This rule is defined by the following XPath expression:

    //LocalVariableDeclaration[ClassType[pmd-java:typeIs('java.util.Calendar')]] |
                    //FormalParameter[ClassType[pmd-java:typeIs('java.util.Calendar')]] |
                    //FieldDeclaration[ClassType[pmd-java:typeIs('java.util.Calendar')]] |
                    //ConstructorCall[ClassType[pmd-java:typeIs('java.util.Calendar')]]

Example(s):

    import java.util.Calendar;
    import java.util.GregorianCalendar;
    import java.time.LocalDate;
    import java.time.LocalDateTime;
    import java.time.ZonedDateTime;

    public class Foo {
        void problematic() {
            // Problematic - using legacy Calendar API
            Calendar cal = Calendar.getInstance();
            cal.set(2024, Calendar.JANUARY, 15); // Month indexing is confusing (0-based)
            cal.add(Calendar.DAY_OF_MONTH, 7);

            Calendar specific = new GregorianCalendar(2024, 0, 15); // Also problematic
        }

        void preferred() {
            // Preferred - using modern java.time API
            LocalDate date = LocalDate.of(2024, 1, 15); // Month indexing is intuitive (1-based)
            LocalDate weekLater = date.plusDays(7);

            LocalDateTime dateTime = LocalDateTime.now();
            ZonedDateTime zonedDateTime = ZonedDateTime.now();
        }
    }

Use this rule by referencing it:

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

## ReplaceJavaUtilDate

Since: PMD 7.16.0

Priority: Medium (3)

Minimum Language Version: Java 1.8

The legacy `java.util.Date` class is mutable, not thread-safe, and has a confusing API. Many of its methods are deprecated, it doesn’t handle timezones properly, and it represents both date and time even when only one is needed. The constructor parameters are particularly error-prone: year is "years since 1900" and month is 0-based (January = 0). The modern java.time API (introduced in Java 8) provides better type safety, immutability, and clearer semantics.

Use `LocalDate` (date only), `LocalTime` (time only), `LocalDateTime` (date and time), `Instant` (timestamp), or `ZonedDateTime` (date-time with timezone) from `java.time` package instead.

Note: This includes subtypes such as `java.sql.Date`, `java.sql.Time` and `java.sql.Timestamp`. Since JPA 3.2 (Jakarta Persistence) usage of `java.util.Date` and `java.util.Calendar` and others is deprecated there as well in favour of `java.time` API.

This rule is defined by the following XPath expression:

    //LocalVariableDeclaration[ClassType[pmd-java:typeIs('java.util.Date')]] |
                    //FormalParameter[ClassType[pmd-java:typeIs('java.util.Date')]] |
                    //FieldDeclaration[ClassType[pmd-java:typeIs('java.util.Date')]] |
                    //ConstructorCall[ClassType[pmd-java:typeIs('java.util.Date')]]

Example(s):

    import java.util.Date;
    import java.time.Instant;
    import java.time.LocalDate;
    import java.time.LocalDateTime;
    import java.time.ZonedDateTime;

    public class Foo {
        void problematic() {
            // Problematic - using legacy Date API
            Date now = new Date();
            Date epoch = new Date(0L);
            Date custom = new Date(124, 0, 15); // Deprecated constructor: year=1900+124=2024, month=0=January

            // Mutable operations are error-prone
            now.setTime(System.currentTimeMillis());
        }

        void preferred() {
            // Preferred - using modern java.time API
            Instant now = Instant.now(); // For timestamps
            LocalDate today = LocalDate.now(); // For date only
            LocalDateTime dateTime = LocalDateTime.now(); // For date and time
            ZonedDateTime zonedDateTime = ZonedDateTime.now(); // With timezone

            // Immutable operations are safer
            LocalDate tomorrow = today.plusDays(1);
            LocalDateTime nextHour = dateTime.plusHours(1);
        }
    }

Use this rule by referencing it:

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

## 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

Since: PMD 2.0

Priority: Medium High (2)

The method name and parameter number are suspiciously close to `Object.equals`, which can denote an intention to override it. However, the method does not override `Object.equals`, but overloads it instead. Overloading `Object.equals` method is confusing for other programmers, error-prone and hard to maintain, especially when using inheritance, because `@Override` annotations used in subclasses can provide a false sense of security. For more information on `Object.equals` method, see Effective Java, 3rd Edition, Item 10: Obey the general contract when overriding equals.

This rule is defined by the following XPath expression:

    //MethodDeclaration[@Name = 'equals'][
        (@Arity = 1
         and not(FormalParameters/FormalParameter[pmd-java:typeIsExactly('java.lang.Object')])
         or not(PrimitiveType[@Kind = 'boolean'])
        ) or (
         @Arity = 2
         and PrimitiveType[@Kind = 'boolean']
         and FormalParameters/FormalParameter[pmd-java:typeIsExactly('java.lang.Object')]
         and not(pmd-java:hasAnnotation('java.lang.Override'))
        )
    ]
    | //MethodDeclaration[@Name = 'equal'][
        @Arity = 1
        and FormalParameters/FormalParameter[pmd-java:typeIsExactly('java.lang.Object')]
    ]

Example(s):

    public class Foo {
       public int equals(Object o) {
         // oops, this probably was supposed to be boolean equals
       }
       public boolean equals(String s) {
         // oops, this probably was supposed to be equals(Object)
       }
       public boolean equals(Object o1, Object o2) {
         // oops, this probably was supposed to be equals(Object)
       }
    }

Use this rule by referencing it:

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

## SuspiciousHashcodeMethodName

Since: PMD 1.5

Priority: Medium (3)

The method name and return type are suspiciously close to hashCode(), which may denote an intention to override the hashCode() method.

This rule is defined by the following XPath expression:

    //MethodDeclaration[
            lower-case(@Name) = 'hashcode'
        and @Name != 'hashCode'
        and @Arity = 0
        and PrimitiveType[@Kind = 'int']
    ]

Example(s):

    public class Foo {
        public int hashcode() { // oops, this probably was supposed to be 'hashCode'
        }
    }

Use this rule by referencing it:

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

## SuspiciousOctalEscape

Since: PMD 1.5

Priority: Medium (3)

A suspicious octal escape sequence was found inside a String literal. The Java language specification (section 3.10.6) says an octal escape sequence inside a literal String shall consist of a backslash followed by:

    OctalDigit | OctalDigit OctalDigit | ZeroToThree OctalDigit OctalDigit

Any octal escape sequence followed by non-octal digits can be confusing, e.g. "\038" is interpreted as the octal escape sequence "\03" followed by the literal character "8".

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

Example(s):

    public void foo() {
      // interpreted as octal 12, followed by character '8'
      System.out.println("suspicious: \128");
    }

Use this rule by referencing it:

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

## TestClassWithoutTestCases

Since: PMD 3.0

Priority: Medium (3)

Test classes typically start or end with the affix "Test", "Tests" or "TestCase". Having a non-test class with that name is not a good practice, since most people will assume it is a test case. Test classes have test methods named "testXXX" (JUnit3) or use annotations (e.g. `@Test`).

The regular expression to match can be configured using the property `testClassPattern`. To disable the detection of possible test classes by name, set this property to an empty string.

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

Example(s):

    //Consider changing the name of the class if it is not a test
    //Consider adding test methods if it is a test
    public class CarTest {
       public static void main(String[] args) {
        // do something
       }
       // code
    }

This rule has the following properties:

Name | Default Value | Description
--- | --- | ---
testClassPattern | ^(?:.*\.)?Test[^\.]*$|^(?:.*\.)?.*Tests?$|^(?:.*\.)?.*TestCase$ | Test class name pattern to identify test classes by their fully qualified name. An empty pattern disables test class detection by name. Since PMD 6.51.0.

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

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

Use this rule and customize it:

    <rule ref="category/java/errorprone.xml/TestClassWithoutTestCases">
        <properties>
            <property name="testClassPattern" value="^(?:.*\.)?Test[^\.]*$|^(?:.*\.)?.*Tests?$|^(?:.*\.)?.*TestCase$" />
        </properties>
    </rule>

## UnconditionalIfStatement

Since: PMD 1.5

Priority: Medium (3)

Do not use "if" statements whose conditionals are always true or always false.

This rule is defined by the following XPath expression:

    //IfStatement[BooleanLiteral[1]]
    union
    //IfStatement/(VariableAccess|UnaryExpression[@Operator = '!']/VariableAccess)/self::VariableAccess[@CompileTimeConstant = false()]
    [@Name = ancestor::IfStatement
             /preceding-sibling::LocalVariableDeclaration[PrimitiveType[@Kind = "boolean"]]
             /VariableDeclarator[@Initializer = true()][BooleanLiteral]
             /@Name]
    (: var is only initialized with a literal and used only with the if statement, there is no other var access :)
    [let $name := @Name return count(ancestor::Block//VariableAccess[@Name = $name]) = 1]

Example(s):

    public class Foo {
        public void close() {
            if (true) {        // fixed conditional, not recommended
                // ...
            }
        }
    }

Use this rule by referencing it:

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

## UnnecessaryBooleanAssertion

Since: PMD 3.0

Priority: Medium (3)

A JUnit test assertion with a boolean literal is unnecessary since it always will evaluate to the same thing. Consider using flow control (in case of `assertTrue(false)` or similar) or simply removing statements like `assertTrue(true)` and `assertFalse(false)`. If you just want a test to halt after finding an error, use the `fail()` method and provide an indication message of why it did.

This rule is defined by the following XPath expression:

    //ClassDeclaration
        [pmd-java:typeIs('junit.framework.TestCase')
         or .//Annotation[pmd-java:typeIs('org.junit.Test')
                       or pmd-java:typeIs('org.junit.jupiter.api.Test')
                       or pmd-java:typeIs('org.junit.jupiter.api.RepeatedTest')
                       or pmd-java:typeIs('org.junit.jupiter.api.TestFactory')
                       or pmd-java:typeIs('org.junit.jupiter.api.TestTemplate')
                       or pmd-java:typeIs('org.junit.jupiter.params.ParameterizedTest')
         ]
        ]
        //MethodCall[@MethodName = ('assertTrue', 'assertFalse')]
            [ArgumentList
                [
                    BooleanLiteral or
                    UnaryExpression[@Operator = '!'][BooleanLiteral]
                ]
            ]

Example(s):

    public class SimpleTest extends TestCase {
        public void testX() {
            assertTrue(true);            // serves no real purpose - remove it
        }
    }

Use this rule by referencing it:

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

## UnnecessaryCaseChange

Since: PMD 3.3

Priority: Medium (3)

Using equalsIgnoreCase() is faster than using toUpperCase/toLowerCase().equals()

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

Example(s):

    boolean answer1 = buz.toUpperCase().equals("BAZ");              // should be buz.equalsIgnoreCase("BAZ")

    boolean answer2 = buz.toUpperCase().equalsIgnoreCase("BAZ");    // another unnecessary toUpperCase()

Use this rule by referencing it:

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

## UnnecessaryConversionTemporary

Since: PMD 0.1

Priority: Medium (3)

Avoid the use temporary objects when converting primitives to Strings. Use the static conversion methods on the wrapper classes instead.

This rule is defined by the following XPath expression:

    //MethodCall[@MethodName = 'toString']
        [ConstructorCall[position() = 1]
            [
                pmd-java:typeIs('java.lang.Integer')
             or pmd-java:typeIs('java.lang.Long')
             or pmd-java:typeIs('java.lang.Float')
             or pmd-java:typeIs('java.lang.Byte')
             or pmd-java:typeIs('java.lang.Double')
             or pmd-java:typeIs('java.lang.Short')
            ]
        ]

Example(s):

    public String convert(int x) {
        String foo = new Integer(x).toString(); // this wastes an object

        return Integer.toString(x);             // preferred approach
    }

Use this rule by referencing it:

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

## UnsupportedJdkApiUsage

Since: PMD 7.21.0

Priority: Medium (3)

Avoid importing classes or using APIs from the `sun.*` or `jdk.internal.*` packages, including `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe`. These packages are neither portable nor stable and may change or be removed in future versions of the JDK. As the name implies, the `Unsafe` class methods are particularly dangerous and have been superseded by safer alternatives, such as the VarHandle API (introduced in JDK 9) and the Foreign Function & Memory API (introduced in JDK 22). Refer to JEP 471 for safer alternatives with examples.

If you must depend on Sun APIs, confine their usage to a minimal, isolated scope, such as within a stable wrapper class. You may suppress this rule in the implementation of such a wrapper, but it’s strongly recommended to migrate to official APIs wherever possible.

The use of such unsupported APIs will also be flagged by the Java compiler, as they are intended strictly for internal purposes. This PMD rule has been added to facilitate independent code reviews and to catch instances where compiler warnings may have been overlooked.

This rule is defined by the following XPath expression:

    //ImportDeclaration[starts-with(@ImportedName, 'sun.') or starts-with(@ImportedName, 'jdk.internal.')]
                        |
                        //MethodCall[pmd-java:matchesSig('sun.misc.Unsafe#_(_*)') or pmd-java:matchesSig('jdk.internal.misc.Unsafe#_(_*)')]

Example(s):

    public final class MemoryWiper {
      public static void main(final String[] args) throws NoSuchFieldException, IllegalAccessException {
        for (final String s : args) {
          sun.misc.Unsafe.getUnsafe().putAddress(Long.parseLong(s), 0L); // bad
        }
      }
    }

Use this rule by referencing it:

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

## UnusedNullCheckInEquals

Since: PMD 3.5

Priority: Medium (3)

After checking an object reference for null, you should invoke equals() on that object rather than passing it to another object’s equals() method.

This rule is defined by the following XPath expression:

    //InfixExpression[@Operator = '&&']
      /MethodCall[pmd-java:matchesSig("java.lang.Object#equals(java.lang.Object)")]
                 [not(StringLiteral)]
                 [not(VariableAccess[@CompileTimeConstant = true()])]
                 [ArgumentList/VariableAccess/@Name = ..//InfixExpression[@Operator = '!='][NullLiteral]/VariableAccess/@Name]

Example(s):

    public class Test {

        public String method1() { return "ok";}
        public String method2() { return null;}

        public void method(String a) {
            String b;
            // I don't know it method1() can be "null"
            // but I know "a" is not null..
            // I'd better write a.equals(method1())

            if (a!=null && method1().equals(a)) { // will trigger the rule
                //whatever
            }

            if (method1().equals(a) && a != null) { // won't trigger the rule
                //whatever
            }

            if (a!=null && method1().equals(b)) { // won't trigger the rule
                //whatever
            }

            if (a!=null && "LITERAL".equals(a)) { // won't trigger the rule
                //whatever
            }

            if (a!=null && !a.equals("go")) { // won't trigger the rule
                a=method2();
                if (method1().equals(a)) {
                    //whatever
                }
            }
        }
    }

Use this rule by referencing it:

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

## UseCorrectExceptionLogging

Since: PMD 3.2

Priority: Medium (3)

To make sure the full stacktrace is printed out, use the logging statement with two arguments: a String and a Throwable.

This rule only applies to Apache Commons Logging.

This rule is defined by the following XPath expression:

    //CatchClause/Block//MethodCall
        [pmd-java:matchesSig('org.apache.commons.logging.Log#_(java.lang.Object)')]
        [ArgumentList[not(MethodCall)]//VariableAccess/@Name = ancestor::CatchClause/CatchParameter/@Name]

Example(s):

    public class Main {
        private static final Log _LOG = LogFactory.getLog( Main.class );
        void bar() {
            try {
            } catch( Exception e ) {
                _LOG.error( e ); //Wrong!
            } catch( OtherException oe ) {
                _LOG.error( oe.getMessage(), oe ); //Correct
            }
        }
    }

Use this rule by referencing it:

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

## UseEqualsToCompareStrings

Since: PMD 4.1

Priority: Medium (3)

Using ‘==’ or ‘!=’ to compare strings is only reliable if the interned string (`String#intern()`) is used on both sides.

Use the `equals()` method instead.

This rule is defined by the following XPath expression:

    //InfixExpression[@Operator = ('==', '!=')]
                     [count(*[pmd-java:typeIsExactly('java.lang.String')]) = 2]

Example(s):

    public boolean test(String s) {
        if (s == "one") return true;        // unreliable
        if ("two".equals(s)) return true;   // better
        return false;
    }

Use this rule by referencing it:

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

## UselessOperationOnImmutable

Deprecated

Since: PMD 3.5

Priority: Medium (3)

An operation on an immutable object will not change the object itself since the result of the operation is a new object. Therefore, ignoring the result of such an operation is likely a mistake. The operation can probably be removed.

This rule recognizes the types `String`, `BigDecimal`, `BigInteger` or any type from `java.time.*` as immutable.

Deprecated: This rule is deprecated since PMD 7.17.0 and will be removed with PMD 8.0.0. This rule has been replaced by `UselessPureMethodCall`.

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

Example(s):

    import java.math.*;

    class Test {
        void method1() {
            BigDecimal bd=new BigDecimal(10);
            bd.add(new BigDecimal(5));      // this will trigger the rule
        }
        void method2() {
            BigDecimal bd=new BigDecimal(10);
            bd = bd.add(new BigDecimal(5)); // this won't trigger the rule
        }
    }

Use this rule by referencing it:

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

## UselessPureMethodCall

Since: PMD 7.17.0

Priority: Medium (3)

This rule detects method calls of pure methods whose result is unused. A pure method is a method without side effects. Therefore, ignoring the result of such a method call is likely a mistake.

Either the method call can be removed or the result should be used.

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

Example(s):

    public class Something {
        public void foo() {
            List.of("foo").size(); // result unused
            Stream.of("bar").map(item -> System.out.format("%s", item)); // result unused
            Stream.of("bar").forEach(item -> System.out.format("%s", item)); // better
        }
    }

Use this rule by referencing it:

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

## UseLocaleWithCaseConversions

Since: PMD 2.0

Priority: Medium (3)

When doing `String::toLowerCase()/toUpperCase()` conversions, use an explicit locale argument to specify the case transformation rules.

Using `String::toLowerCase()` without arguments implicitly uses `Locale::getDefault()`. The problem is that the default locale depends on the current JVM setup (and usually on the system in which it is running). Using the system default may be exactly what you want (e.g. if you are manipulating strings you got through standard input), but it may as well not be the case (e.g. if you are getting the string over the network or a file, and the encoding is well-defined and independent of the environment). In the latter case, using the default locale makes the case transformation brittle, as it may yield unexpected results on a machine whose locale has other case translation rules. For example, in Turkish, the uppercase form of `i` is `İ` (U+0130, not ASCII) and not `I` (U+0049) as in English.

The rule is intended to force developers to think about locales when dealing with strings. By taking a conscious decision about the choice of locale at the time of writing, you reduce the risk of surprising behaviour down the line, and communicate your intent to future readers.

This rule is defined by the following XPath expression:

    //MethodCall[pmd-java:matchesSig("java.lang.String#toLowerCase()") or pmd-java:matchesSig("java.lang.String#toUpperCase()")]
                [not(MethodCall[@MethodName = "toHexString"])]

Example(s):

    // violation - implicitly system-dependent conversion
    if (x.toLowerCase().equals("list")) {}

    // The above will not match "LIST" on a system with a Turkish locale.
    // It could be replaced with
    if (x.toLowerCase(Locale.US).equals("list")) { }
    // or simply
    if (x.equalsIgnoreCase("list")) { }

    // ok - system independent conversion
    String z = a.toLowerCase(Locale.ROOT);

    // ok - explicit system-dependent conversion
    String z2 = a.toLowerCase(Locale.getDefault());

Use this rule by referencing it:

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

## UseProperClassLoader

Since: PMD 3.7

Priority: Medium (3)

In J2EE, the getClassLoader() method might not work as expected. Use Thread.currentThread().getContextClassLoader() instead.

This rule is defined by the following XPath expression:

    //MethodCall[pmd-java:matchesSig("java.lang.Class#getClassLoader()")]

Example(s):

    public class Foo {
        ClassLoader cl = Bar.class.getClassLoader();
    }

Use this rule by referencing it:

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