Skip to content

PMD - pull_request #963

PMD - pull_request

PMD - pull_request #963

Triggered via pull request November 13, 2025 14:48
Status Success
Total duration 31s
Artifacts 1

check-pmd.yml

on: pull_request
pmd_analyse
26s
pmd_analyse
Fit to window
Zoom out
Zoom in

Annotations

10 errors
Avoid using implementation types like 'HashMap'; use the interface instead: powertools-parameters/powertools-parameters-dynamodb/src/test/java/software/amazon/lambda/powertools/parameters/dynamodb/DynamoDbProviderTest.java#L79
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: 1, Ruleset: Best Practices) https://docs.pmd-code.org/snapshot/pmd_rules_java_bestpractices.html#loosecoupling
The final field tableName could be made static: powertools-parameters/powertools-parameters-dynamodb/src/test/java/software/amazon/lambda/powertools/parameters/dynamodb/DynamoDbProviderTest.java#L50
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: 1, Ruleset: Design) https://docs.pmd-code.org/snapshot/pmd_rules_java_design.html#finalfieldcouldbestatic
Explicit type arguments can be replaced by a diamond: `new HashMap<>()`: powertools-parameters/powertools-parameters-dynamodb/src/test/java/software/amazon/lambda/powertools/parameters/dynamodb/DynamoDbProviderE2ETest.java#L87
In some cases, explicit type arguments in a constructor call for a generic type may be replaced by diamond type arguments (`<>`), and be inferred by the compiler. This rule recommends that you use diamond type arguments anywhere possible, since it avoids duplication of the type arguments, and makes the code more concise and readable. This rule is useful when upgrading a codebase to Java 1.7, Java 1.8, or Java 9. The diamond syntax was first introduced in Java 1.7. In Java 8, improvements in Java's type inference made more type arguments redundant. In Java 9, type arguments inference was made possible for anonymous class constructors. UseDiamondOperator (Priority: 1, Ruleset: Code Style) https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#usediamondoperator
Avoid using implementation types like 'HashMap'; use the interface instead: powertools-parameters/powertools-parameters-dynamodb/src/test/java/software/amazon/lambda/powertools/parameters/dynamodb/DynamoDbProviderE2ETest.java#L87
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: 1, Ruleset: Best Practices) https://docs.pmd-code.org/snapshot/pmd_rules_java_bestpractices.html#loosecoupling
Explicit type arguments can be replaced by a diamond: `new HashMap<>()`: powertools-parameters/powertools-parameters-dynamodb/src/test/java/software/amazon/lambda/powertools/parameters/dynamodb/DynamoDbProviderE2ETest.java#L78
In some cases, explicit type arguments in a constructor call for a generic type may be replaced by diamond type arguments (`<>`), and be inferred by the compiler. This rule recommends that you use diamond type arguments anywhere possible, since it avoids duplication of the type arguments, and makes the code more concise and readable. This rule is useful when upgrading a codebase to Java 1.7, Java 1.8, or Java 9. The diamond syntax was first introduced in Java 1.7. In Java 8, improvements in Java's type inference made more type arguments redundant. In Java 9, type arguments inference was made possible for anonymous class constructors. UseDiamondOperator (Priority: 1, Ruleset: Code Style) https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#usediamondoperator
Avoid using implementation types like 'HashMap'; use the interface instead: powertools-parameters/powertools-parameters-dynamodb/src/test/java/software/amazon/lambda/powertools/parameters/dynamodb/DynamoDbProviderE2ETest.java#L78
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: 1, Ruleset: Best Practices) https://docs.pmd-code.org/snapshot/pmd_rules_java_bestpractices.html#loosecoupling
Explicit type arguments can be replaced by a diamond: `new HashMap<>()`: powertools-parameters/powertools-parameters-dynamodb/src/test/java/software/amazon/lambda/powertools/parameters/dynamodb/DynamoDbProviderE2ETest.java#L58
In some cases, explicit type arguments in a constructor call for a generic type may be replaced by diamond type arguments (`<>`), and be inferred by the compiler. This rule recommends that you use diamond type arguments anywhere possible, since it avoids duplication of the type arguments, and makes the code more concise and readable. This rule is useful when upgrading a codebase to Java 1.7, Java 1.8, or Java 9. The diamond syntax was first introduced in Java 1.7. In Java 8, improvements in Java's type inference made more type arguments redundant. In Java 9, type arguments inference was made possible for anonymous class constructors. UseDiamondOperator (Priority: 1, Ruleset: Code Style) https://docs.pmd-code.org/snapshot/pmd_rules_java_codestyle.html#usediamondoperator
Avoid using implementation types like 'HashMap'; use the interface instead: powertools-parameters/powertools-parameters-dynamodb/src/test/java/software/amazon/lambda/powertools/parameters/dynamodb/DynamoDbProviderE2ETest.java#L58
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: 1, Ruleset: Best Practices) https://docs.pmd-code.org/snapshot/pmd_rules_java_bestpractices.html#loosecoupling
The final field MultiparamsTestTable could be made static: powertools-parameters/powertools-parameters-dynamodb/src/test/java/software/amazon/lambda/powertools/parameters/dynamodb/DynamoDbProviderE2ETest.java#L42
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: 1, Ruleset: Design) https://docs.pmd-code.org/snapshot/pmd_rules_java_design.html#finalfieldcouldbestatic
The final field ParamsTestTable could be made static: powertools-parameters/powertools-parameters-dynamodb/src/test/java/software/amazon/lambda/powertools/parameters/dynamodb/DynamoDbProviderE2ETest.java#L41
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: 1, Ruleset: Design) https://docs.pmd-code.org/snapshot/pmd_rules_java_design.html#finalfieldcouldbestatic

Artifacts

Produced during runtime
Name Size Digest
PMD Report
2.48 KB
sha256:4161c8c71532fa3af9ad023a08fb1fdd41096fb3de496b178f916bc62a5d3033