Add `rewrite` support for `errorprone.refasterrules`

[Pankraz76]

Add rewrite support for errorprone.refasterrules

I propose integrating Google Error Prone (https://github.com/google/error-prone) with its Picnic extension (demo: https://www.youtube.com/watch?v=6llnrUtVlrE) to enable automated fixes via rewrite rules.
This would complement Checkstyle by addressing semantic bugs rather than just stylistic issues.

Motivation

Error Prone’s refaster/rewrite rules can:

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

Adoption examples:

• [openrewrite] add tech.picnic.errorprone.refasterrules diffplug/spotless#2641
• Apply StreamRulesRecipes apache/maven#11159
• Issue #17487: Add StreamRulesRecipes apache/maven-parent#496
• Add rewrite support for errorprone.refasterrules checkstyle/checkstyle#17487
• PoC: Add rewrite support for errorprone.refasterrules apache/kafka#20219
• PoC: Add rewrite support for errorprone.refasterrules diffplug/spotless#2576

Proposal

1. Support errorprone.refasterrules rewrites
2. Keep adoption opt-in (no breaking changes)
3. Provide suppression mechanisms for API constraints

Open Questions

• Scope of auto-fixes
• Suppression strategy
• Integration approach

Next Steps

I can:

• Prepare a PoC
• Help with implementation design
• Address compatibility concerns

[Pankraz76]

Earlier objections are resolved. The tool is already in productive use across major projects we depend on, so we’re already benefiting from it indirectly.

Why not adopt it directly and reduce the manual burden?

[jbduncan]

My biggest objection right now is how slow the OpenRewrite Gradle plugin is - developer experience is important to me - so if it were me, I would just run it once and accept any fixes that it suggests.

However, I'm not a JUnit maintainer, so I'll leave it to the team to decide next steps. :)

[Pankraz76]

Thanks for the nice argumentation and layout of the issue.

Initially, it’s even faster (2 sec.) than Spot, which is quite a surprise.
In the end, though, it’s quite an investment. PMD is also not much faster or slower at this scale.

• [openrewrite] initial merge and UpgradeToJava17 diffplug/spotless#2636

Spot, on the other hand, contains almost every recipe we can imagine, and it doesn’t slow down development.

• [openrewrite] add SanityCheck featuring CommonStaticAnalysis diffplug/spotless#2651

[jbduncan]

Initially, it’s even faster (2 sec.) than Spot, which is quite a surprise.

Oh, really?

In my personal project, Spotless runs orders of magnitude faster than OpenRewrite, especially on subsequent re-runs.

But if there are CI stats to prove it and the team has anecdotal evidence that OpenRewrite is fast enough for local development, then I'm more open to it being used in JUnit. :)

[marcphilipp]

As a first step, I'd suggest adding tech.picnic.error-prone-support:error-prone-contrib to see if that reports any findings.

[Pankraz76]

You’re asking for https://error-prone.picnic.tech/#gradle, right?
Unfortunately, using Google Error Prone also Picnic is quite a hassle and not very user-friendly compared to the Rewrite integration.

In the end, it’s the same — but it’s much more suitable to use Rewrite directly as the vehicle to deliver the Refaster rules.

When adding some Error Prone recipes, we can already see certain changes.
Fortunately, some of the recipes you added — like the security ones — remain clean,
so the changes are still intact.

• [openrewrite] add SanityCheck featuring tech.picnic.errorprone.refasterrules #5003

[marcphilipp]

You’re asking for error-prone.picnic.tech#gradle, right?
Unfortunately, using Google Error Prone also Picnic is quite a hassle and not very user-friendly compared to the Rewrite integration.

Yes, we have already set up and configured Error Prone so adding another dependency should be simple.