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! 👍

[marcphilipp]

Are you going to address these (except DirectReturn) in separate PRs?

[Pankraz76]

Yes, Lexa is something easy to consider, if this meets the taste of the community.

• Issue #14194: Add LexicographicalAnnotationListing checkstyle/checkstyle#17892

Static import is something to suggest to avoid lots of redundant context. Collection. stuff.

ConstantNaming is also kind of a no-brainer, as it's the quintessence of JCC, but here it's not fixable.
We'll handle this successfully in Spotless, so this is something to investigate further.

Everything else is then up to the community, kind of, as we definitely need all of these, as we are failing them even though it should not be necessary! (since they are not all error severity, but even low-level like suggestion). Isn't it? @rickie

This itself indicates some misconfigured or problematic tooling.

Thank you both for the great learning experience - both technical and foremost in social regards, which is kind of a big challenge for me personally.

Please excuse me for being inconsistent sometimes.

[Pankraz76]

now its very clear, thanks.