Introduce additional Reactor Refaster rules

[Stephan202]

Suggested commit message:

Introduce additional Reactor Refaster rules (#969)

In various contexts, suggest more efficient and/or less verbose
constructs.

[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.

[werli]

Cool stuff

[werli]

Food for thought: MathFlux#max returns a Mono, so the resulting Flux has either zero or one element. Should we make this more explicit but using Flux#singleOrEmpty()? This comment applies for more parts of the PR.

Suggested change

	return flux.transform(MathFlux::max).next();
	return flux.transform(MathFlux::max).singleOrEmpty();

[Stephan202]

Nice suggestion; applied!

[werli]

Maybe this opens up a box of other possible improvements.

Any conversion Mono -> Flux -> Mono for which we know at most one element emitted and that's currently using Flux#next should be rewritten? E.g. flux.transform(xyz -> mono).next() could call Flux#singleOrEmpty().

[Stephan202]

Indeed. There's a whole class of "replace operator based on an invariant established by preceding operators" rewrite rules, where these invariants are often of the form "between x and y elements will be emitted". In some cases it may be more efficient/practical to introduce an Error Prone check for that, like we did for NonEmptyMono.

I was planning to add a commit with two more rules:

• One that matches your suggestion, with a note to generalize it later.
• Another that I came up with when writing a test case for the first. This one cleans up a pattern found in our codebase.

(The idea being that this is a lightweight approach to tracking these ideas.)

... however, the first of these rules doesn't work, due to what appears to be a bug in Refaster's matching of generic types. I previously hit a similar issue, so I added this rule to another branch.

[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.

[Venorcis]

LGTM 👍🏻

[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.

[sonarcloud]

Quality Gate passed

Kudos, no new issues were introduced!

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

See analysis details on SonarCloud

[rickie]

LGTM!

[rickie]

Let's also apply this in the other before template :).

EDIT: It doesn't work, because (correct me if I'm wrong): it doesn't make sense to go from something that is a super type of I to something that is a subtype of I, (or I), right?

[Stephan202]

Hmm, it could make sense, but using I instead of ? extends Iterable<? extends S> would impose a greater restriction than necessary or desired: the rule should also work for any Iterable that is not a sub- or super-type of I.