Upgrade Checkstyle to latest version and modernize `storm_checkstyle.xml`

[GGraziadei]

The project is currently using a significantly outdated version of Checkstyle (v8.2).
This version is several years old and lacks support for modern Java syntax and improved linting features found in the latest releases.
https://mvnrepository.com/artifact/com.puppycrawl.tools/checkstyle/versions

Continuing with this outdated version presents several issues:

• Strict import enforcement: Newer versions of Checkstyle handle CustomImportOrder differently. We are currently seeing warnings (or being forced into specific import hacks) regarding the STATIC group because the old version's rules are inconsistent with modern IDE defaults.
• Configuration inconsistency: the file storm_checkstyle.xml is based on an ancient version of Google’s checkstyle config (v7.7). Many properties used in our XML are deprecated or have been removed in Checkstyle 10+, making the current configuration incompatible with the latest tooling.
• Modern Java support.

Proposed Changes:

• Bump dependency
• Update storm_checkstyle.xml

[rzo1]

This can be done, but it might require to go module by module - otherwise, potential checkstyle violations and their fixes become unreviewable.

[GGraziadei]

Hi @rzo1,

I have explored several paths for this update. First, I found the targeting version 12.3.1 (according to the compatibility matrix), as it is the last checkstyle version developed with Java 17, ensuring maximum compatibility with the maven-checkstyle-plugin.

I’ve evaluated two main strategies:

Strategy 1: Update the ceckstyle configuration. This involves adopting updated rules (e.g., Google Checks 12.3.1) and skipping auto-generated code. Pros: Up-to-date standards. Cons: This would require touching almost every file in the project, which may not provide enough benefit to justify the effort.

Strategy 2: Keep custom rules but fix mandatory violations. This would involve keeping our current rules while fixing only the mandatory violations introduced by the new version. Even when using tools like OpenRewrite https://docs.openrewrite.org/ to automate the process, a large percentage of files would still need modifications.

In both cases, the cost-benefit analysis leans negative. What do you think?

[rzo1]

Storm 3 will Most likely target Java 21 (as discussed on dev).

Yes, migrating is a lot of mechanical work. If someone wants to do it, I am fine with 1 or 2.

Only thing is, that it needs to be done step by step. Otherwise, reviewing is Not feasable