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

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

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

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

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

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

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

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

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