Process completed with exit code 1.

Reassigning values to incoming parameters of a method or constructor is not recommended, as this can make the code more difficult to understand. The code is often read with the assumption that parameter values don't change and an assignment violates therefore the principle of least astonishment. This is especially a problem if the parameter is documented e.g. in the method's javadoc and the new content differs from the original documented content. Use temporary local variables instead. This allows you to assign a new name, which makes the code better understandable. Note that this rule considers both methods and constructors. If there are multiple assignments for a formal parameter, then only the first assignment is reported. AvoidReassigningParameters (Priority: 2, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_bestpractices.html#avoidreassigningparameters

Reassigning values to incoming parameters of a method or constructor is not recommended, as this can make the code more difficult to understand. The code is often read with the assumption that parameter values don't change and an assignment violates therefore the principle of least astonishment. This is especially a problem if the parameter is documented e.g. in the method's javadoc and the new content differs from the original documented content. Use temporary local variables instead. This allows you to assign a new name, which makes the code better understandable. Note that this rule considers both methods and constructors. If there are multiple assignments for a formal parameter, then only the first assignment is reported. AvoidReassigningParameters (Priority: 2, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_bestpractices.html#avoidreassigningparameters

Excessive coupling to implementation types (e.g., `HashSet`) limits your ability to use alternate implementations in the future as requirements change. Whenever available, declare variables and parameters using a more general type (e.g, `Set`). This rule reports uses of concrete collection types. User-defined types that should be treated the same as interfaces can be configured with the property `allowedTypes`. LooseCoupling (Priority: 3, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_bestpractices.html#loosecoupling

New objects created within loops should be checked to see if they can created outside them and reused. AvoidInstantiatingObjectsInLoops (Priority: 3, Ruleset: Performance) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_performance.html#avoidinstantiatingobjectsinloops

Position literals first in all String comparisons, if the second argument is null then NullPointerExceptions can be avoided, they will just return false. Note that switching literal positions for compareTo and compareToIgnoreCase may change the result, see examples. LiteralsFirstInComparisons (Priority: 3, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_bestpractices.html#literalsfirstincomparisons

Avoid assignments in operands; this can make code more complicated and harder to read. AssignmentInOperand (Priority: 3, Ruleset: Error Prone) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_errorprone.html#assignmentinoperand

Avoid concatenating characters as strings in StringBuffer/StringBuilder.append methods. AppendCharacterWithChar (Priority: 3, Ruleset: Performance) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_performance.html#appendcharacterwithchar

Java 5 introduced the varargs parameter declaration for methods and constructors. This syntactic sugar provides flexibility for users of these methods and constructors, allowing them to avoid having to deal with the creation of an array. Byte arrays in any method and String arrays in `public static void main(String[])` methods are ignored. UseVarargs (Priority: 4, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_bestpractices.html#usevarargs

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

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

Using constants in interfaces is a bad practice. Interfaces define types, constants are implementation details better placed in classes or enums. If the constants are best viewed as members of an enumerated type, you should export them with an enum type. For other scenarios, consider using a utility class. See Effective Java's 'Use interfaces only to define types'. ConstantsInInterface (Priority: 3, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_bestpractices.html#constantsininterface