checkstyle

A command substitution such as CS_version=$(getCheckstylePomVersion) does not stop the script by itself. If Maven fails, the script can continue with invalid or empty output and later produce confusing errors such as Unrecognized option. Add an explicit status check after the call:

CS_version="$(getPomVersion)" || {
  echo "Failed to determine Checkstyle POM version" >&2
  exit 1
}

For robust fail-fast behavior, also add at the top of the script:

set -euo pipefail

pipefail is important when the function pipes Maven output to grep, sed, or similar commands; otherwise the pipeline can succeed even if Maven fails. Keep the version lookup in a helper and apply the guard at every call site, as done in Checkstyle's .ci/util.sh, validation.sh, no-exception-test.sh, and release scripts.

This is a Checkstyle bug in versions such as 14.2.0: accessor detection skips // single-line comments but not /* ... */ block comments, so a block comment can prevent a valid getter/setter from being recognized. Upgrade to a Checkstyle release containing the fix for issue #21755. As a workaround, replace block comments inside the accessor with single-line comments, remove them, or suppress MissingJavadocMethod for the affected methods. For example, use // comment instead of /* block comment */ in the method body.

Checkstyle 14.1.0 can enter an infinite loop in SinglelineDetector.checkLine when a suppressed match has zero width, such as (?=TODO) inside a comment. The code calls matcher.find(startPosition) and sets startPosition = matcher.end(), but for a zero-width match start and end are equal, so the same match is found repeatedly.

The merged fix replaces matcher.find(startPosition) with matcher.find(), allowing the matcher to advance past empty matches. Upgrade to a Checkstyle release containing the fix for issue #21519.

As a workaround, replace the zero-width pattern with a consuming pattern. For this example, use:

<property name="format" value="TODO"/>

With ignoreComments=true, matches in comments are still suppressed and TODO in code is reported. Avoid lookaheads or other patterns that can produce an empty match until you run the fixed version.

This is a known Checkstyle RequireThisCheck bug (#5353), affecting at least Checkstyle 8.8. When an anonymous class extends a type that declares a field with the same name as a field in the enclosing class, the unqualified reference resolves to the anonymous object's inherited field, but Checkstyle incorrectly reports it as the outer field.

Fix: upgrade to a Checkstyle release containing the #5353 fix, preferably the latest version, and rerun:

java -jar checkstyle-latest-all.jar -c TestConfig.xml TestClass.java

If you cannot upgrade immediately, qualify the inherited reference explicitly:

f = 1;

this.f = 1;

DescendantTokenCheck.countTokens traverses the AST recursively, so one extremely deep expression (thousands of + operands in a single statement, e.g. generated code) overflows the JVM stack before the violation can be reported. Fixed by PR #21902, which replaces the recursive walk with an iterative traversal (matching the parser's non-recursive handling, see JavaAstVisitorTest#testNoStackOverflowOnDeepStringConcat) — upgrade to a Checkstyle release containing that fix. Workarounds until then: (1) enlarge the thread stack: java -Xss8m -jar checkstyle-14.3.0-all.jar -c config.xml Test.java (increase -Xss until the run completes); (2) split the expression into multiple shorter statements or intermediate variables to reduce AST depth; (3) exclude the problematic/generated file via BeforeExecutionExclusionFileFilter. Note that SuppressionFilter/SuppressionXpathFilter will NOT help — the crash occurs during traversal, before any violation event is created.