PMD - pull_request #963
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
|
|