Whenever using a log level, one should check if it is actually enabled, or otherwise skip the associate String creation and manipulation, as well as any method calls. An alternative to checking the log level are substituting parameters, formatters or lazy logging with lambdas. The available alternatives depend on the actual logging framework. GuardLogStatement (Priority: 2, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_bestpractices.html#guardlogstatement

Whenever using a log level, one should check if it is actually enabled, or otherwise skip the associate String creation and manipulation, as well as any method calls. An alternative to checking the log level are substituting parameters, formatters or lazy logging with lambdas. The available alternatives depend on the actual logging framework. GuardLogStatement (Priority: 2, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_bestpractices.html#guardlogstatement

Whenever using a log level, one should check if it is actually enabled, or otherwise skip the associate String creation and manipulation, as well as any method calls. An alternative to checking the log level are substituting parameters, formatters or lazy logging with lambdas. The available alternatives depend on the actual logging framework. GuardLogStatement (Priority: 2, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_bestpractices.html#guardlogstatement

Whenever using a log level, one should check if it is actually enabled, or otherwise skip the associate String creation and manipulation, as well as any method calls. An alternative to checking the log level are substituting parameters, formatters or lazy logging with lambdas. The available alternatives depend on the actual logging framework. GuardLogStatement (Priority: 2, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_bestpractices.html#guardlogstatement

Whenever using a log level, one should check if it is actually enabled, or otherwise skip the associate String creation and manipulation, as well as any method calls. An alternative to checking the log level are substituting parameters, formatters or lazy logging with lambdas. The available alternatives depend on the actual logging framework. GuardLogStatement (Priority: 2, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_bestpractices.html#guardlogstatement

Whenever using a log level, one should check if it is actually enabled, or otherwise skip the associate String creation and manipulation, as well as any method calls. An alternative to checking the log level are substituting parameters, formatters or lazy logging with lambdas. The available alternatives depend on the actual logging framework. GuardLogStatement (Priority: 2, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_bestpractices.html#guardlogstatement

Whenever using a log level, one should check if it is actually enabled, or otherwise skip the associate String creation and manipulation, as well as any method calls. An alternative to checking the log level are substituting parameters, formatters or lazy logging with lambdas. The available alternatives depend on the actual logging framework. GuardLogStatement (Priority: 2, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_bestpractices.html#guardlogstatement

Whenever using a log level, one should check if it is actually enabled, or otherwise skip the associate String creation and manipulation, as well as any method calls. An alternative to checking the log level are substituting parameters, formatters or lazy logging with lambdas. The available alternatives depend on the actual logging framework. GuardLogStatement (Priority: 2, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_bestpractices.html#guardlogstatement

Whenever using a log level, one should check if it is actually enabled, or otherwise skip the associate String creation and manipulation, as well as any method calls. An alternative to checking the log level are substituting parameters, formatters or lazy logging with lambdas. The available alternatives depend on the actual logging framework. GuardLogStatement (Priority: 2, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_bestpractices.html#guardlogstatement

Whenever using a log level, one should check if it is actually enabled, or otherwise skip the associate String creation and manipulation, as well as any method calls. An alternative to checking the log level are substituting parameters, formatters or lazy logging with lambdas. The available alternatives depend on the actual logging framework. GuardLogStatement (Priority: 2, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_bestpractices.html#guardlogstatement

A logger should normally be defined private static final and be associated with the correct class. `private final Log log;` is also allowed for rare cases where loggers need to be passed around, with the restriction that the logger needs to be passed into the constructor. ProperLogger (Priority: 3, Ruleset: Error Prone) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_errorprone.html#properlogger

Reports exceptions that are thrown from within a catch block, yet don't refer to the exception parameter declared by that catch block. The stack trace of the original exception could be lost, which makes the thrown exception less informative. To preserve the stack trace, the original exception may be used as the cause of the new exception, using `Throwable#initCause`, or passed as a constructor argument to the new exception. It may also be preserved using `Throwable#addSuppressed`. The rule actually assumes that any method or constructor that takes the original exception as argument preserves the original stack trace. The rule allows `InvocationTargetException` and `PrivilegedActionException` to be replaced by their cause exception. The discarded part of the stack trace is in those cases only JDK-internal code, which is not very useful. The rule also ignores exceptions whose name starts with `ignored`. PreserveStackTrace (Priority: 3, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_bestpractices.html#preservestacktrace

Reports exceptions that are thrown from within a catch block, yet don't refer to the exception parameter declared by that catch block. The stack trace of the original exception could be lost, which makes the thrown exception less informative. To preserve the stack trace, the original exception may be used as the cause of the new exception, using `Throwable#initCause`, or passed as a constructor argument to the new exception. It may also be preserved using `Throwable#addSuppressed`. The rule actually assumes that any method or constructor that takes the original exception as argument preserves the original stack trace. The rule allows `InvocationTargetException` and `PrivilegedActionException` to be replaced by their cause exception. The discarded part of the stack trace is in those cases only JDK-internal code, which is not very useful. The rule also ignores exceptions whose name starts with `ignored`. PreserveStackTrace (Priority: 3, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_bestpractices.html#preservestacktrace

Position literals first in all String comparisons, if the second argument is null then NullPointerExceptions can be avoided, they will just return false. Note that switching literal positions for compareTo and compareToIgnoreCase may change the result, see examples. Note that compile-time constant strings are treated like literals. This is because they are inlined into the class file, are necessarily non-null, and therefore cannot cause an NPE at runtime. LiteralsFirstInComparisons (Priority: 3, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_bestpractices.html#literalsfirstincomparisons

Reports exceptions that are thrown from within a catch block, yet don't refer to the exception parameter declared by that catch block. The stack trace of the original exception could be lost, which makes the thrown exception less informative. To preserve the stack trace, the original exception may be used as the cause of the new exception, using `Throwable#initCause`, or passed as a constructor argument to the new exception. It may also be preserved using `Throwable#addSuppressed`. The rule actually assumes that any method or constructor that takes the original exception as argument preserves the original stack trace. The rule allows `InvocationTargetException` and `PrivilegedActionException` to be replaced by their cause exception. The discarded part of the stack trace is in those cases only JDK-internal code, which is not very useful. The rule also ignores exceptions whose name starts with `ignored`. PreserveStackTrace (Priority: 3, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_bestpractices.html#preservestacktrace

Reports exceptions that are thrown from within a catch block, yet don't refer to the exception parameter declared by that catch block. The stack trace of the original exception could be lost, which makes the thrown exception less informative. To preserve the stack trace, the original exception may be used as the cause of the new exception, using `Throwable#initCause`, or passed as a constructor argument to the new exception. It may also be preserved using `Throwable#addSuppressed`. The rule actually assumes that any method or constructor that takes the original exception as argument preserves the original stack trace. The rule allows `InvocationTargetException` and `PrivilegedActionException` to be replaced by their cause exception. The discarded part of the stack trace is in those cases only JDK-internal code, which is not very useful. The rule also ignores exceptions whose name starts with `ignored`. PreserveStackTrace (Priority: 3, Ruleset: Best Practices) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_bestpractices.html#preservestacktrace

A logger should normally be defined private static final and be associated with the correct class. `private final Log log;` is also allowed for rare cases where loggers need to be passed around, with the restriction that the logger needs to be passed into the constructor. ProperLogger (Priority: 3, Ruleset: Error Prone) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_errorprone.html#properlogger

Uncommented Empty Constructor finds instances where a constructor does not contain statements, but there is no comment. By explicitly commenting empty constructors it is easier to distinguish between intentional (commented) and unintentional empty constructors. UncommentedEmptyConstructor (Priority: 3, Ruleset: Documentation) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_documentation.html#uncommentedemptyconstructor

This rule detects when a constructor is not necessary; i.e., when there is only one constructor and the constructor is identical to the default constructor. The default constructor should has same access modifier as the declaring class. In an enum type, the default constructor is implicitly private. UnnecessaryConstructor (Priority: 3, Ruleset: Code Style) https://docs.pmd-code.org/pmd-doc-7.12.0/pmd_rules_java_codestyle.html#unnecessaryconstructor