Process completed with exit code 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. ConstructorCallsOverridableMethod (Priority: 1, Ruleset: Error Prone) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_errorprone.html#constructorcallsoverridablemethod

References to System.(out|err).print are usually intended for debugging purposes and can remain in the codebase even in production code. By using a logger one can enable/disable this behaviour at will (and by priority) and avoid clogging the Standard out log. SystemPrintln (Priority: 2, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_bestpractices.html#systemprintln

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

The job was canceled because "ubuntu-latest" failed.

The operation was canceled.

The job was canceled because "ubuntu-latest" failed.

The operation was canceled.

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

Java will initialize fields with known default values so any explicit initialization of those same defaults is redundant and results in a larger class file (approximately three additional bytecode instructions per field). RedundantFieldInitializer (Priority: 3, Ruleset: Performance) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_performance.html#redundantfieldinitializer

Identifies a possible unsafe usage of a static field. AssignmentToNonFinalStatic (Priority: 3, Ruleset: Error Prone) https://docs.pmd-code.org/pmd-doc-7.9.0/pmd_rules_java_errorprone.html#assignmenttononfinalstatic

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

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

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

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

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