Serguey Asael Shinder: Checkstyle 14.3 ships a module-info, 39 minutes after 14.2 fixed checks on new syntax
Checkstyle published two releases on 27 September, and they are worth reading separately.
14.2.0 came out at 14:43 UTC with the usual long list. The release on GitHub adds new checks such as UnnecessaryPermitsClause, JavadocSeeTagOrder and OpenjdkMethodThrowsAlignment, and most of the rest are false positives and false negatives. Two caught my eye because they are about recent Java syntax.
The first is #21739: UnusedLocalVariable reported an unnamed variable _ as an unused named variable, but only inside a method of an anonymous class. The same var _ = ...; in an ordinary method was correctly ignored, because allowUnnamedVariables defaults to true. The reporter ran it on JDK 25. The second pair is LambdaParameterName and NeedBraces silently passing lambdas inside a switch rule. A check that stays quiet on new syntax is the harder failure to notice, because a clean report looks the same as a correct one.
The notes also list #10924, which asks that all checks that use AbstractCheck#getLine() measure spacing in code points rather than char values. It was opened in November 2021 and the issue itself is still open, so I read its appearance in the notes as progress on it rather than the end of it. I wrote about why the distinction matters in a separate note on String.length().
14.3.0 followed at 15:22 UTC, and its release notes contain a single line: Checkstyle is now a Java module. The comparison between the two tags shows five commits, and the only code change is a new module-info.java for issue #14120, opened in December 2023 by someone whose own custom checks got a warning about an "unstable module name derived from the file name". Until now the JVM derived the module name checkstyle from the jar file name. The module is now called com.puppycrawl.tools.checkstyle.
The descriptor declares the whole module open, and its comment explains why: Checkstyle instantiates modules by name from user configuration, sets properties through reflection, and loads message bundles from many packages, so listing each package to open would have to be kept in sync forever. Compile-time visibility is still governed by the exports clauses.
What I would check before upgrading. If you only run Checkstyle from Maven or Gradle on the classpath, 14.3.0 should behave like 14.2.0. If you build custom checks and put Checkstyle on the module path, any requires checkstyle; has to become requires com.puppycrawl.tools.checkstyle;, because the automatic name no longer exists. That is a one-line change, but it is the kind of one-line change that fails a build rather than a test.