Extend CollectionIsEmpty Refaster rule

[giovannizotta]

Add the following expression to CollectionIsEmpty: collection.stream().findAny().isEmpty().

Clashing issue

Currently, this rule clashes with the rule OptionalFirstCollectionElement, which is matching collection.stream().findAny(), rewriting it to collection.stream().findFirst(). Not sure what's the best way to solve this issue, both use cases seem valid 🤔

1. Suppressing the suggestion to rewrite collection.stream().findAny().isEmpty() to collection.stream().findFirst().isEmpty() leads to a loop since stream().findFirst().isEmpty() is rewritten to stream().findAny().isEmpty()

Benefits

This acts as a useful partner to StreamIsEmpty: expressions that match the one introduced in this PR can result as a consequence of applying the StreamIsEmpty rule: this allows for refactors like the following to be applied in multiple steps:

1. collection.stream().collect(collectingAndThen(toImmutableList(), List::isEmpty))
3. collection.stream().findAny().isEmpty()
4. collection.isEmpty()

[github-actions]

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

[Stephan202]

Right, so we generally prefer findFirst() over findAny() (because in the vast majority of cases the former better expresses semantics), but when followed by isEmpty()/isPresent() we prefer the latter. This is a bit of a quirk in our setup; usually we try to avoid those "contextual preferences", as it can cause a combinatorial explosion of cases to consider.

So a second option would be to change the other rules to unconditionally prefer findFirst(). But in this case I think a suppression may be nicer. I rebased and pushed a proposal :)

Suggested commit message:

Extend `CollectionIsEmpty` Refaster rule (#1027)

[Stephan202]

So OptionalFirstCollectionElement and StreamIsEmpty prefer different variants. But our Refaster integration prefers writing the longest expression matched, so this one will win.

[giovannizotta]

Understood, I was wondering indeed what happens when an expression is matched by multiple rules. It makes sense that the longest one wins 👍

[Stephan202]

Yeah; implemented here :)

[github-actions]

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

[giovannizotta]

Thank you @Stephan202, indeed the need for suppression comes from the fact that we're "inconsistent" over the preference of findAny() and findFirst(). The suggestions LGTM, thanks a lot!

[github-actions]

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

[github-actions]

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

[rickie]

🚀

[github-actions]

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud