Improvement of Type Safety and Revapi error "Method Return Type Changed Covariantly"

[nikolassv]

When combining Unis (e.g. Uni.combine().all().unis(...)) and limiting concurrency (.usingConcurrencyOf(x)), we currently lose type information. This occurs because the usingConcurrencyOf method is defined only for UniAndGroupIterable, not in the UniAndGroupX classes (which support up to 9 typed unis).

For example, in the io.smallrye.mutiny.operators.UniZipTest.ConcurrencyLimitTest#combineAllSmokeTest:

@Test
void combineAllSmokeTest() {
    Uni<Integer> a = Uni.createFrom().item(1);
    Uni<Integer> b = Uni.createFrom().item(2);
    Uni<Integer> c = Uni.createFrom().item(3);
    Uni<Integer> d = Uni.createFrom().item(4);

    UniAssertSubscriber<? extends List<?>> sub = Uni.combine().all().unis(a, b, c, d)
            .usingConcurrencyOf(1)
            .with(unis -> unis)
            .subscribe().withSubscriber(UniAssertSubscriber.create());

    sub.assertCompleted();
    assertThat(sub.getItem()).asInstanceOf(LIST).containsExactly(1, 2, 3, 4);
}

Here Uni.combine().all().unis(a, b, c, d) returns an UniAndGroup4<Integer, Integer, Integer, Integer> the usingConcurrencyOf method returns a UniAndGroupIterable<Integer> which leads to loss of type information. This issues is especially significant when working with Unis of different types (a real life example can be found in this Stackoverflow post: https://stackoverflow.com/questions/79169458/how-to-escape-continuation-hell/79170157#79170157).

I tried to address the situation by overriding the usingConcurrencyOf method in the UniAndGroupX classed. This solution maintains the source API without breaking any existing test. However, Revapi flags it as a binary incompatibility issue due to a covariant return type change (see https://revapi.org/revapi-java/0.28.1/differences.html#java.method.returnTypeChangedCovariantly).

Would this binary incompatibility be a blocker, or would you still consider a PR with this change? Additionally, what would be the best approach for handling the Revapi issue in this case?

[jponge]

Justifications for breaking changes with RevAPI can be added to https://github.com/smallrye/smallrye-mutiny/blob/main/implementation/revapi.json#L54

I'd be happy to have a look at your PR, such case is indeed tricky and we might accept a binary incompatibility if that improves the API ergonomics. And in the worst case scenario we can stage that for a major release under semantic versioning assumptions.

Thanks!

[nikolassv]

Thank you for the reply! I have created a PR for my changes: #1736