Chore/ensure pmd failure #286
Annotations
2 errors and 10 warnings
|
The final local variable name 'FAILURE_STATUSES' doesn't match '[a-z][a-zA-Z0-9]*':
src/main/java/uk/gov/hmcts/cp/cdk/jobmanager/caseflow/CheckIngestionStatusForDocumentTask.java#L75
Configurable naming conventions for local variable declarations and other locally-scoped
variables. This rule reports variable declarations which do not match the regex that applies to their
specific kind (e.g. final variable, or catch-clause parameter). Each regex can be configured through
properties.
By default this rule uses the standard Java naming convention (Camel case).
LocalVariableNamingConventions (Priority: 1, Ruleset: Code Style)
https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#localvariablenamingconventions
|
|
The constant name 'log' doesn't match '[A-Z][A-Z_0-9]*':
src/main/java/uk/gov/hmcts/cp/cdk/jobmanager/caseflow/CheckIngestionStatusForDocumentTask.java#L47
Configurable naming conventions for field declarations. This rule reports variable declarations
which do not match the regex that applies to their specific kind ---e.g. constants (static final),
enum constant, final field. Each regex can be configured through properties.
By default this rule uses the standard Java naming convention (Camel case), and uses the ALL_UPPER
convention for constants and enum constants.
FieldNamingConventions (Priority: 1, Ruleset: Code Style)
https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#fieldnamingconventions
|
|
Avoid unused local variables such as 'jobCtx'.:
src/main/java/uk/gov/hmcts/cp/cdk/batch/tasklet/GenerateAnswersTasklet.java#L110
Detects when a local variable is declared and/or assigned, but not used.
Variables whose name starts with `ignored` or `unused` are filtered out.
UnusedLocalVariable (Priority: 3, Ruleset: Best Practices)
https://docs.pmd-code.org/snapshot/pmd_rules_java_bestpractices.html#unusedlocalvariable
|
|
Missing commented default access modifier on nested class 'CaseStatusRowMapper':
src/main/java/uk/gov/hmcts/cp/cdk/batch/partition/ReadyCasePartitioner.java#L173
To avoid mistakes if we want that an Annotation, Class, Enum, Method, Constructor or Field have a default access modifier
we must add a comment at the beginning of its declaration.
By default, the comment must be `/* default */` or `/* package */`, if you want another, you have to provide a regular expression.
This rule ignores by default all cases that have a `@VisibleForTesting` annotation or any JUnit5/TestNG annotation. Use the
property "ignoredAnnotations" to customize the recognized annotations.
CommentDefaultAccessModifier (Priority: 3, Ruleset: Code Style)
https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#commentdefaultaccessmodifier
|
|
Missing commented default access modifier on nested record 'CaseStatusRow':
src/main/java/uk/gov/hmcts/cp/cdk/batch/partition/ReadyCasePartitioner.java#L165
To avoid mistakes if we want that an Annotation, Class, Enum, Method, Constructor or Field have a default access modifier
we must add a comment at the beginning of its declaration.
By default, the comment must be `/* default */` or `/* package */`, if you want another, you have to provide a regular expression.
This rule ignores by default all cases that have a `@VisibleForTesting` annotation or any JUnit5/TestNG annotation. Use the
property "ignoredAnnotations" to customize the recognized annotations.
CommentDefaultAccessModifier (Priority: 3, Ruleset: Code Style)
https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#commentdefaultaccessmodifier
|
|
A method should have only one exit point, and that should be the last statement in the method:
src/main/java/uk/gov/hmcts/cp/cdk/batch/partition/ReadyCasePartitioner.java#L142
A method should have only one exit point, and that should be the last statement in the method.
OnlyOneReturn (Priority: 3, Ruleset: Code Style)
https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#onlyonereturn
|
|
Unnecessary explicit boxing:
src/main/java/uk/gov/hmcts/cp/cdk/batch/partition/ReadyCasePartitioner.java#L135
Reports explicit boxing and unboxing conversions that may safely be removed,
either because they would be inserted by the compiler automatically,
or because they're semantically a noop (eg unboxing a value to rebox it immediately).
Note that this only handles boxing and unboxing conversions occurring through
calls to `valueOf` or one of the `intValue`, `byteValue`, etc. methods. Casts
that command a conversion are reported by {% rule UnnecessaryCast %} instead.
UnnecessaryBoxing (Priority: 3, Ruleset: Code Style)
https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#unnecessaryboxing
|
|
Avoid instantiating new objects inside loops:
src/main/java/uk/gov/hmcts/cp/cdk/batch/partition/ReadyCasePartitioner.java#L119
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
|
|
Unnecessary explicit boxing:
src/main/java/uk/gov/hmcts/cp/cdk/batch/partition/ReadyCasePartitioner.java#L108
Reports explicit boxing and unboxing conversions that may safely be removed,
either because they would be inserted by the compiler automatically,
or because they're semantically a noop (eg unboxing a value to rebox it immediately).
Note that this only handles boxing and unboxing conversions occurring through
calls to `valueOf` or one of the `intValue`, `byteValue`, etc. methods. Casts
that command a conversion are reported by {% rule UnnecessaryCast %} instead.
UnnecessaryBoxing (Priority: 3, Ruleset: Code Style)
https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#unnecessaryboxing
|
|
Unnecessary @SuppressWarnings annotation:
src/main/java/uk/gov/hmcts/cp/cdk/batch/partition/ReadyCasePartitioner.java#L93
This rule reports suppression comments and annotations that did not suppress any PMD violation.
Note that violations of this rule cannot be suppressed.
Please note:
- The rule will report those suppressions comments/annotations that did not suppress a violation
_during the current run_. That means you cannot run this rule separately from other rules, it must
always be run with all the rules that could produce a warning. This is most likely not a problem, as
you can just include this rule in your regular ruleset.
- The rule for now only reports annotations specific to PMD, like `@SuppressWarnings("PMD")`. For instance
`@SuppressWarnings("all")` is never reported as we cannot know if another tool is producing a
warning there that must be suppressed. In the future we might be able to check for other common ones
like `@SuppressWarnings("unchecked")` or `"fallthrough"`.
UnnecessaryWarningSuppression (Priority: 3, Ruleset: Best Practices)
https://docs.pmd-code.org/snapshot/pmd_rules_java_bestpractices.html#unnecessarywarningsuppression
|
|
Missing commented default access modifier on field 'materialToCaseMap':
src/main/java/uk/gov/hmcts/cp/cdk/batch/partition/EligibleMaterialCasePartitioner.java#L27
To avoid mistakes if we want that an Annotation, Class, Enum, Method, Constructor or Field have a default access modifier
we must add a comment at the beginning of its declaration.
By default, the comment must be `/* default */` or `/* package */`, if you want another, you have to provide a regular expression.
This rule ignores by default all cases that have a `@VisibleForTesting` annotation or any JUnit5/TestNG annotation. Use the
property "ignoredAnnotations" to customize the recognized annotations.
CommentDefaultAccessModifier (Priority: 3, Ruleset: Code Style)
https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#commentdefaultaccessmodifier
|
|
Avoid catching RuntimeException in try-catch block:
src/main/java/uk/gov/hmcts/cp/cdk/batch/BatchConfig.java#L256
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
AvoidCatchingGenericException (Priority: 3, Ruleset: Error Prone)
https://docs.pmd-code.org/snapshot/pmd_rules_java_errorprone.html#avoidcatchinggenericexception
|
Artifacts
Produced during runtime
| Name | Size | Digest | |
|---|---|---|---|
|
PMD Report
|
10.9 KB |
sha256:c0d7bdd0c2bce9f924cad1f62ff5e511e0882dd1e897ff0db8ab7aa49bfb3530
|
|