[GR-68578] 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:

• Issue #17487: Add rewrite support checkstyle/checkstyle#17545
• Fix #5953: [java] PoC: Add rewrite support for errorprone.refasterrules pmd/pmd#5956
• Apply RemoveUnusedPrivateMethods opensearch-project/OpenSearch#18791
• PoC: Add rewrite support for errorprone.refasterrules diffplug/spotless#2576
• PoC: Add rewrite support for errorprone.refasterrules apache/kafka#20219

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

Feature request

Please include the following information:

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. E.g. I'm always frustrated when [...]

Describe the solution you'd like.
A clear and concise description of what you want to happen.

Describe who do you think will benefit the most.
GraalVM users, GraalVM contributors, developers of libraries and frameworks which depend on GraalVM, or somebody else?

Describe alternatives you've considered.
A clear and concise description of any alternative solutions or features you've considered.

Additional context.
Add any other context about the feature request here.
For example, link to the relevant projects, documentation, standards.

Express whether you'd like to help contributing this feature
If you'd like to contribute, please read the contribution guide.

[selhagani]

Hi @Pankraz76,

Thank you for reaching out to us about this. We will take a closer look into it and I'll make sure to keep you updated.

[selhagani]

Hi @Pankraz76,

Could you please run the tool against the Graal compiler sources and submit a pull request illustrating the types of issues it identifies? This will help us evaluate the potential value it can provide.

[Pankraz76]

Yes will provide.

Feel free to consider these as examples too:

• Add rewrite support for gradle.GradleBestPractices hibernate/hibernate-orm#10731
• Add staticanalysis.UnnecessaryParentheses google/guava#7916

Security issue:

• Add rewrite support for gradle.GradleBestPractices hibernate/hibernate-orm#10731 (comment)

It's about the big picture - for code it's functionality, and in this PR it's about the functionality to streamline - being able to align at scale, just like what's already been done with tools like Spotless.

Of course, this is just some Proof of Concept. Which recipe is beneficial has to be decided by the dev team, not me.

• [GR-68578] Apply RemoveUnusedImports #11928
• [GR-68578] Apply openrewrite.maven.BestPractices #11929

[Pankraz76]

This looks strange whats the default? assuming the second one? right? now i know how i did not was able to add the plugin but had to rely on CLI mode.

Convention is this:

Config is this:

Meaning having to config the pom.xml to open the "right" project. Might be a bug in idea as the project structure is like expected.

• https://youtrack.jetbrains.com/issue/IJPL-201461/Import-not-working-out-of-the-box