slurm monitor - #21

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/snapshot/pmd_rules_java_errorprone.html#constructorcallsoverridablemethod

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/snapshot/pmd_rules_java_errorprone.html#constructorcallsoverridablemethod

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 ReturnEmptyCollectionRatherThanNull (Priority: 1, Ruleset: Error Prone) https://docs.pmd-code.org/snapshot/pmd_rules_java_errorprone.html#returnemptycollectionratherthannull

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 ReturnEmptyCollectionRatherThanNull (Priority: 1, Ruleset: Error Prone) https://docs.pmd-code.org/snapshot/pmd_rules_java_errorprone.html#returnemptycollectionratherthannull

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 ReturnEmptyCollectionRatherThanNull (Priority: 1, Ruleset: Error Prone) https://docs.pmd-code.org/snapshot/pmd_rules_java_errorprone.html#returnemptycollectionratherthannull

The FileInputStream and FileOutputStream classes contains a finalizer method which will cause garbage collection pauses. See [JDK-8080225](https://bugs.openjdk.org/browse/JDK-8080225) for details. The FileReader and FileWriter constructors instantiate FileInputStream and FileOutputStream, again causing garbage collection issues while finalizer methods are called. * Use `Files.newInputStream(Paths.get(fileName))` instead of `new FileInputStream(fileName)`. * Use `Files.newOutputStream(Paths.get(fileName))` instead of `new FileOutputStream(fileName)`. * Use `Files.newBufferedReader(Paths.get(fileName))` instead of `new FileReader(fileName)`. * Use `Files.newBufferedWriter(Paths.get(fileName))` instead of `new FileWriter(fileName)`. Please note, that the `java.nio` API does not throw a `FileNotFoundException` anymore, instead it throws a `NoSuchFileException`. If your code dealt explicitly with a `FileNotFoundException`, then this needs to be adjusted. Both exceptions are subclasses of `IOException`, so catching that one covers both. AvoidFileStream (Priority: 1, Ruleset: Performance) https://docs.pmd-code.org/snapshot/pmd_rules_java_performance.html#avoidfilestream

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 ReturnEmptyCollectionRatherThanNull (Priority: 1, Ruleset: Error Prone) https://docs.pmd-code.org/snapshot/pmd_rules_java_errorprone.html#returnemptycollectionratherthannull

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 ReturnEmptyCollectionRatherThanNull (Priority: 1, Ruleset: Error Prone) https://docs.pmd-code.org/snapshot/pmd_rules_java_errorprone.html#returnemptycollectionratherthannull

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 ReturnEmptyCollectionRatherThanNull (Priority: 1, Ruleset: Error Prone) https://docs.pmd-code.org/snapshot/pmd_rules_java_errorprone.html#returnemptycollectionratherthannull

The FileInputStream and FileOutputStream classes contains a finalizer method which will cause garbage collection pauses. See [JDK-8080225](https://bugs.openjdk.org/browse/JDK-8080225) for details. The FileReader and FileWriter constructors instantiate FileInputStream and FileOutputStream, again causing garbage collection issues while finalizer methods are called. * Use `Files.newInputStream(Paths.get(fileName))` instead of `new FileInputStream(fileName)`. * Use `Files.newOutputStream(Paths.get(fileName))` instead of `new FileOutputStream(fileName)`. * Use `Files.newBufferedReader(Paths.get(fileName))` instead of `new FileReader(fileName)`. * Use `Files.newBufferedWriter(Paths.get(fileName))` instead of `new FileWriter(fileName)`. Please note, that the `java.nio` API does not throw a `FileNotFoundException` anymore, instead it throws a `NoSuchFileException`. If your code dealt explicitly with a `FileNotFoundException`, then this needs to be adjusted. Both exceptions are subclasses of `IOException`, so catching that one covers both. AvoidFileStream (Priority: 1, Ruleset: Performance) https://docs.pmd-code.org/snapshot/pmd_rules_java_performance.html#avoidfilestream

Node.js 20 is deprecated. The following actions target Node.js 20 but are being forced to run on Node.js 24: actions/checkout@v4, actions/setup-java@v3, pmd/pmd-github-action@v2. For more information see: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/

setup-java v3 is deprecated and will no longer receive updates. Please migrate to actions/setup-java@v5.

Cannot build an overlay database because build-mode is set to "undefined" instead of "none". Falling back to creating a normal full database instead.

When you write a public method, you should be thinking in terms of an API. If your method is public, it means other class will use it, therefore, you want (or need) to offer a comprehensive and evolutive API. If you pass a lot of information as a simple series of Strings, you may think of using an Object to represent all those information. You'll get a simpler API (such as doWork(Workload workload), rather than a tedious series of Strings) and more importantly, if you need at some point to pass extra data, you'll be able to do so by simply modifying or extending Workload without any modification to your API. **Deprecated:** This rule is deprecated since PMD 7.26.0 and will be removed with PMD 8.0.0. Use {% rule ExcessiveParameterList %} instead. UseObjectForClearerAPI (Priority: 3, Ruleset: Design) https://docs.pmd-code.org/snapshot/pmd_rules_java_design.html#useobjectforclearerapi

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/snapshot/pmd_rules_java_performance.html#avoidinstantiatingobjectsinloops

Avoid creating deeply nested if-then statements since they are harder to read and error-prone to maintain. AvoidDeeplyNestedIfStmts (Priority: 3, Ruleset: Design) https://docs.pmd-code.org/snapshot/pmd_rules_java_design.html#avoiddeeplynestedifstmts

A local variable assigned only once can be declared final. LocalVariableCouldBeFinal (Priority: 3, Ruleset: Code Style) https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#localvariablecouldbefinal

The complexity of methods directly affects maintenance costs and readability. Concentrating too much decisional logic in a single method makes its behaviour hard to read and change. Cyclomatic complexity assesses the complexity of a method by counting the number of decision points in a method, plus one for the method entry. Decision points are places where the control flow jumps to another place in the program. As such, they include all control flow statements, such as `if`, `while`, `for`, and `case`. For more details on the calculation, see the documentation {% jdoc java::lang.java.metrics.JavaMetrics#CYCLO %}. Generally, numbers ranging from 1-4 denote low complexity, 5-7 denote moderate complexity, 8-10 denote high complexity, and 11+ is very high complexity. By default, this rule reports methods with a complexity >= 10. Additionally, classes with many methods of moderate complexity get reported as well once the total of their methods' complexities reaches 80, even if none of the methods was directly reported. Reported methods should be broken down into several smaller methods. Reported classes should probably be broken down into subcomponents. CyclomaticComplexity (Priority: 3, Ruleset: Design) https://docs.pmd-code.org/snapshot/pmd_rules_java_design.html#cyclomaticcomplexity

Methods that are highly complex are difficult to read and more costly to maintain. If you include too much decisional logic within a single method, you make its behavior hard to understand and more difficult to modify. Cognitive complexity is a measure of how difficult it is for humans to read and understand a method. Code that contains a break in the control flow is more complex, whereas the use of language shorthands doesn't increase the level of complexity. Nested control flows can make a method more difficult to understand, with each additional nesting of the control flow leading to an increase in cognitive complexity. Information about Cognitive complexity can be found in the original paper here: <https://www.sonarsource.com/docs/CognitiveComplexity.pdf> By default, this rule reports methods with a complexity of 15 or more. Reported methods should be broken down into less complex components. CognitiveComplexity (Priority: 3, Ruleset: Design) https://docs.pmd-code.org/snapshot/pmd_rules_java_design.html#cognitivecomplexity

Reports method and constructor parameters that can be made final because they are never reassigned within the body of the method. This rule ignores unused parameters so as not to overlap with the rule {% rule java/bestpractices/UnusedFormalParameter %}. It will also ignore the parameters of abstract methods. MethodArgumentCouldBeFinal (Priority: 3, Ruleset: Code Style) https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#methodargumentcouldbefinal

A class with too many methods is probably a good suspect for refactoring, in order to reduce its complexity and find a way to have more fine grained objects. TooManyMethods (Priority: 3, Ruleset: Design) https://docs.pmd-code.org/snapshot/pmd_rules_java_design.html#toomanymethods

Reports method and constructor parameters that can be made final because they are never reassigned within the body of the method. This rule ignores unused parameters so as not to overlap with the rule {% rule java/bestpractices/UnusedFormalParameter %}. It will also ignore the parameters of abstract methods. MethodArgumentCouldBeFinal (Priority: 3, Ruleset: Code Style) https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#methodargumentcouldbefinal