Add error-prone.picnic.tech featuring RedundantStringConversion

[Pankraz76]

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

---

Definition of Done

• There are no TODOs left in the code
• Method preconditions are checked and documented in the method's Javadoc
• Coding conventions (e.g. for logging) have been followed
• Change is covered by automated tests including corner cases, errors, and exception handling
• Public API has Javadoc and @API annotations
• Change is documented in the User Guide and Release Notes

Links:

• Add rewrite support for errorprone.refasterrules #5002 (comment)
• https://github.com/gradle/gradle/blob/dea495b3b841ceaea73c5832ae5bb6b04333b0fc/build-logic-commons/gradle-plugin/src/main/kotlin/gradlebuild.code-quality.gradle.kts#L148
• https://medium.com/@lfgcampos/error-prone-error-pruning-8f1eb51da5ca
• https://sonarsource.github.io/rspec/#/rspec/S1488

[Pankraz76]

2ct.

[Pankraz76]

thanks for the effort spend.

[Pankraz76]

ready to go.

[Pankraz76]

using the in_place mode only works with whitelisting which is is not the desired case. It would still fail on ci demanding fixes but thats not a good behavior.

Prone demands the manual fixes, not being an rewrite equivlent therefore a new mode might be needed.

[marcphilipp]

@Pankraz76 Could you please summarize the state of this PR? Is it ready to be reviewed? What do the changes mean for local builds and on CI?

[Pankraz76]

Explanation

Sorry for the confusion, and thanks for considering.

This is just a new error-prone check, originating from Picnic, and it behaves the same as the other rules for all builds.
If the check finds an issue, it will fail the build and show a suggested fix, just like its currently the case with others.

We can’t use the optional patching mode (IN_PLACE) because it overrides the rule settings when activated.
While this could work locally, it would require significant overhead — such as maintaining an explicit whitelist to keep the ruleset in sync.
Otherwise, a locally green build might still fail in CI, as some checks aren’t included, imposing a rule delta between local and CI builds, which is not the ideal path.
This would lead to manual intervention, which patching is meant to avoid (similar to what’s done with rewrite).

That means only the specified checks would run — leading to a successful local build but a failed CI build, since CI does not patch and still enforces all rules for quality control.

In order to have patching, we would either need to

• adapt Error Prone to support this as a new feature or
• create a whitelist approach similar to Spotless.

Both options are unrealistic, so we should move forward with the current setup and leave the patching topic aside for now — to stop staring and start finishing.
This can be revisited later, along with considerations like StaticImport.

Currently, Spotless uses a fully configured ruleset, which checks only the configured rules instead of following the convention.
While this allows auto-fix capability, it’s not ideal in terms of maintaining consistency with conventions.

Given that the required changes here are minimal, keeping our current setup is the better approach.

related:

• https://github.com/diffplug/spotless/pull/2664/files#r2416889516
• Apply errorprone suggestions using PatchLocation:IN_PLACE for DefaultCharset gradle/gradle#35107

[Pankraz76]

now its small enough to be considerable. Thanks.

[marcphilipp]

Thanks for the summary, that helped! 👍