Add `rewrite` support for `errorprone.refasterrules`

[Pankraz76]

Add rewrite support for errorprone.refasterrules

I’d like to propose integrating Google’s Error Prone and its Picnic extension (demonstrated in Automating Away Bugs with Error Prone | PlatformCon 2023) to enable automated bug fixes via rewrite rules. This would complement Checkstyle’s static analysis capabilities by addressing semantic bugs rather than stylistic issues.

Motivation

Error Prone’s refaster/rewrite rules can automatically:

• Fix common bug patterns (e.g., String.equals() misuse)
• Modernize code (e.g., JDK migration helpers)
• Enforce best practices (e.g., null-check improvements)

Real-world adoptions show tangible benefits:

• Apache Kafka’s integration
• Spotless’s implementation
• Issue #17487: Add rewrite support for errorprone.refasterrules checkstyle/checkstyle#17490

Proposal

1. Add support for errorprone.refasterrules-based rewrites
2. Implement with opt-in adoption (no breaking changes)
3. Include suppression mechanisms for API constraints

Discussion Points

• Need consensus on:
  • Scope of auto-fixes
  • Preferred suppression strategy
  • Integration approach

Next Steps

I’m happy to:

• Prepare a PoC demonstrating the value
• Collaborate on implementation strategy
• Address any concerns about compatibility

[bclozel]

We're not interested at the moment.

The main motivation behind the introduction of errorprone was the nullaway checks. Our current checkstyle setup is good enough for the team and most contributors. We could move towards more automation and more precise style rules with spring-javaformat (this includes IDE plugins and automated formatting), but so far we never felt the need to go further in that direction.

As you've seen with #35243 and many related PRs, it's often complex to come up with generic rules in Framework. Unlike applications, we have to write code in imperative/functional fashions, low/high level abstractions, java agents and bytecode manipulation.

We can reopen this in the future is we consider we need more, but the team is currently focused on delivering 7.0 and supporting other Spring projects in doing so.