Process completed with exit code 1.

Process completed with exit code 1.

Process completed with exit code 1.

ubuntu-latest pipelines will use ubuntu-24.04 soon. For more details, see https://github.com/actions/runner-images/issues/10636

Reports non-final fields whose value never changes once object initialization ends, and hence may be marked final. Note that this rule does not enforce that the field value be deeply immutable itself. An object can still have mutable state, even if all its member fields are declared final. This is referred to as shallow immutability. For more information on mutability, see *Effective Java, 3rd Edition, Item 17: Minimize mutability*. Limitations: We can only check private fields for now. ImmutableField (Priority: 3, Ruleset: Design) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_design.html#immutablefield

Switch statements should be exhaustive, to make their control flow easier to follow. This can be achieved by adding a `default` case, or, if the switch is on an enum type, by ensuring there is one switch branch for each enum constant. This rule doesn't consider Switch Statements, that use Pattern Matching, since for these the compiler already ensures that all cases are covered. The same is true for Switch Expressions, which are also not considered by this rule. NonExhaustiveSwitch (Priority: 3, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_bestpractices.html#nonexhaustiveswitch

Detects when a private field is declared and/or assigned a value, but not used. Since PMD 6.50.0 private fields are ignored, if the fields are annotated with any annotation or the enclosing class has any annotation. Annotations often enable a framework (such as dependency injection, mocking or e.g. Lombok) which use the fields by reflection or other means. This usage can't be detected by static code analysis. Previously these frameworks where explicitly allowed by listing their annotations in the property "ignoredAnnotations", but that turned out to be prone of false positive for any not explicitly considered framework. UnusedPrivateField (Priority: 3, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_bestpractices.html#unusedprivatefield

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. AvoidFieldNameMatchingTypeName (Priority: 3, Ruleset: Error Prone) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_errorprone.html#avoidfieldnamematchingtypename

If a final field is assigned to a compile-time constant, it could be made static, thus saving overhead in each object at runtime. FinalFieldCouldBeStatic (Priority: 3, Ruleset: Design) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_design.html#finalfieldcouldbestatic

Reports assignments to variables that are never used before the variable is overwritten, or goes out of scope. Unused assignments are those for which 1. The variable is never read after the assignment, or 2. The assigned value is always overwritten by other assignments before the next read of the variable. The rule tracks assignements to fields of `this`, and static fields of the current class. This may cause some false positives in timing-sensitive concurrent code, which the rule cannot detect. The rule may be suppressed with the standard `@SuppressWarnings("unused")` tag. The rule subsumes {% rule "UnusedLocalVariable" %}, and {% rule "UnusedFormalParameter" %}. Those violations are filtered out by default, in case you already have enabled those rules, but may be enabled with the property `reportUnusedVariables`. Variables whose name starts with `ignored` or `unused` are filtered out, as is standard practice for exceptions. Limitations: * The rule currently cannot know which method calls throw exceptions, or which exceptions they throw. In the body of a try block, every method or constructor call is assumed to throw. This may cause false-negatives. The only other language construct that is assumed to throw is the `throw` statement, in particular, things like `assert` statements, or NullPointerExceptions on dereference are ignored. * The rule cannot resolve assignments across constructors, when they're called with the special `this(...)` syntax. This may cause false-negatives. Both of those limitations may be partly relaxed in PMD 7. UnusedAssignment (Priority: 3, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_bestpractices.html#unusedassignment

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. AvoidFieldNameMatchingTypeName (Priority: 3, Ruleset: Error Prone) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_errorprone.html#avoidfieldnamematchingtypename

If a final field is assigned to a compile-time constant, it could be made static, thus saving overhead in each object at runtime. FinalFieldCouldBeStatic (Priority: 3, Ruleset: Design) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_design.html#finalfieldcouldbestatic

Reports assignments to variables that are never used before the variable is overwritten, or goes out of scope. Unused assignments are those for which 1. The variable is never read after the assignment, or 2. The assigned value is always overwritten by other assignments before the next read of the variable. The rule tracks assignements to fields of `this`, and static fields of the current class. This may cause some false positives in timing-sensitive concurrent code, which the rule cannot detect. The rule may be suppressed with the standard `@SuppressWarnings("unused")` tag. The rule subsumes {% rule "UnusedLocalVariable" %}, and {% rule "UnusedFormalParameter" %}. Those violations are filtered out by default, in case you already have enabled those rules, but may be enabled with the property `reportUnusedVariables`. Variables whose name starts with `ignored` or `unused` are filtered out, as is standard practice for exceptions. Limitations: * The rule currently cannot know which method calls throw exceptions, or which exceptions they throw. In the body of a try block, every method or constructor call is assumed to throw. This may cause false-negatives. The only other language construct that is assumed to throw is the `throw` statement, in particular, things like `assert` statements, or NullPointerExceptions on dereference are ignored. * The rule cannot resolve assignments across constructors, when they're called with the special `this(...)` syntax. This may cause false-negatives. Both of those limitations may be partly relaxed in PMD 7. UnusedAssignment (Priority: 3, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_bestpractices.html#unusedassignment

Java allows the use of several variables declaration of the same type on one line. However, it can lead to quite messy code. This rule looks for several declarations on the same line. OneDeclarationPerLine (Priority: 4, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_bestpractices.html#onedeclarationperline

ubuntu-latest pipelines will use ubuntu-24.04 soon. For more details, see https://github.com/actions/runner-images/issues/10636

ubuntu-latest pipelines will use ubuntu-24.04 soon. For more details, see https://github.com/actions/runner-images/issues/10636