Issue #17487: Add StreamRulesRecipes

[Pankraz76]

Inspired by:

What’s good for Checkstyle performance could also be beneficial for Maven.

• Issue #17487: Add StreamRulesRecipes checkstyle/checkstyle#17782
• [openrewrite] add tech.picnic.errorprone.refasterrules diffplug/spotless#2641
• [openrewrite] initial merge and UpgradeToJava17 diffplug/spotless#2636
• Apply StreamRulesRecipes maven#11159
• https://error-prone.picnic.tech/refasterrules/StreamRules/
• https://docs.openrewrite.org/recipes/tech/picnic/errorprone/refasterrules/streamrulesrecipes

Yes, it’s Rewrite that was rejected — but actually it’s just the vehicle. Think of it as an obsolete implementation detail, not the real point. The end product is the abstraction. So everyone — lovers and haters (sometimes the same people!) — can be satisfied. We’re not using Rewrite itself, only using it as a means to an end, right?

In reality, we’re following Google’s approach, interpreted and refined with the help of the Picnic team, while also aligning with the benefits delivered through Gradle’s integration of Error Prone:

• Apply errorprone suggestions using PatchLocation:IN_PLACE for KillLeakingJavaProcesses gradle/gradle#35019

[Pankraz76]

@gnodet @elharo

having it running it spot and check, its save to say its already (transient) a part of this project.

If you want to integrate this as well, im here to help.

• [openrewrite] add tech.picnic.errorprone.refasterrules diffplug/spotless#2641

[elharo]

I'm skeptical. It seems likely that some of the suggested changes will sometimes wrong. I'd need to understand exactly what is being changed and why. E.g. checks for misuse of equals are often incorrect when dealing with test code,

[Pankraz76]

skeptical

That's good!

E.g. checks for misuse of equals are often incorrect when dealing with test code,

Off topic.

Please focus only on streams; everything else is obsolete to this issue.

This is an example of "bad" merging, since it's not separated but bundled with broad Picnic fixes.
On the other hand, it shows there’s actually no real need for debate, since Picnic has always promised to be opinionated only on "no-brainers."
That means changes that clearly make sense. If there’s even a little skepticism, it’s not done, to avoid unnecessary hustle.

Other issues, like removing unused code, are a good example of something everyone wants.
Of course it's not perfect, since sometimes exclusions are needed, but that’s still much cheaper than carrying the endless burden of constantly dealing with the same problem:

• Remove unused private methods maven#11165
• https://docs.openrewrite.org/recipes/staticanalysis/removeunusedprivatemethods

[elharo]

The issue is not no-brainers. It's whether the no-brainers can be incorporated in static analysis without using AI or solving the halting problem. I'm not convinced it can. Should unused code be removed? Yes. Can static analysis identify unused code without false positives. No.

I think you're convincing me that I do not want any semantic rewrite rules in the build.

[Pankraz76]

Its just yet another SCA-tool.

Currently there is none. ErrorProne is already capable of handling even the non-private aspects, which involves some real "magic", considering:

• Fix UnusedMethod gradle/gradle#35127
• Fix UnusedMethod & Finally gradle/gradle#34881
• S1144: Unused "private" methods should be removed gradle/gradle#34905

So actually, there is nothing new here—we’re having the same arguments as before. If we go to the quintessence of it, what I’m asking for is automation, which is precisely what this project is supposed to be about, right? Just like Gradle.

They have already realized and admitted that manual effort does not scale.

I’m not asking for a rewrite in particular, since the tool is only a vehicle. The core principle is: invest in automation once, reap the benefits continuously.

We can, of course, achieve the same with Google ErrorProne and Picoc (or similar), but at a much higher cost in effort. The real question is whether we want to repeat manual fixes forever—or embrace automation where it clearly works.

[elharo]

I'm fine with warnings. I'm not OK with automated rewrites of code.

[Pankraz76]

as suggest/requested.

[Pankraz76]

just like done in spot. we use it like PMD, giving warnings as suggested.

• https://github.com/diffplug/spotless/blob/main/.github/workflows/ci.yml#L34

[Pankraz76]

imho, it seems we are using spotless @elharo

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

[slachiewicz]

Thank you for proposal - not yet this time

[Pankraz76]

Apprechiate the feedback, of course — I’m here to help.

If you’re open to it, we could also consider another tool to prevent repetitive manual tasks.
This would make development more scalable and reduce recurring issues.

Why Automation?

Instead of fixing the same problems repeatedly, we can use tools like PMD or Error Prone.
They help detect and prevent issues early in the process.

Examples where automation already helped:

• Remove unused private methods maven#11165
• Apply StreamRulesRecipes maven#11159

Benefits

• Cuts down on manual effort
• Improves consistency
• Scales development without overloading maintainers

Next Steps

If there’s interest, I’d be glad to help explore this further.
It doesn’t have to be a specific tool (like Rewrite) — the key is adopting automation once and reaping continuous benefits.

---

💡 Summary:

• Manual fixes don’t scale
• Automation avoids recurring issues
• Proven value in past PRs
• I can help with integration

[elharo]

The question is not whether to automate. The question is whether specific proposed automations are accurate and useful. And the burden of proof is on the proposer to demonstrate that they are. A change may be good, but not be self-evidently good. If so, it's not going in until a compelling case is made.