RxJava 2.0.5 breaks transformers in Kotlin

[vRallev]

This is very likely related to #4972.

My method signature looks like this

public static <T> ObservableTransformer<T, T> takeWhileViewAttachedObservable(Presenter presenter) {}

This is a generic transformer which we reuse in our project. In Java 7 it was possible to specify the type, so that subscribers below knew the correct type

.compose(Transformers.<String>takeWhileViewAttachedObservable(presenter))

Even better in Java 8 and Kotlin we could avoid the type declaration.

After updating to 2.0.5 our code in Kotlin broke. Subscribers below the compose() method, didn't see the correct type anymore, but only Any (equivalent to Object).

.compose(Transformers.takeWhileViewAttachedObservable(presenter))
.subscribe {
    val myString = it // is not a string anymore
}

I changed the method signature from our reusable transformer to

public static <T> ObservableTransformer<? super T, ? extends T> takeWhileViewAttachedObservable(Presenter presenter) {}

That fixed the problem in Kotlin, but now Java 8 code is complaining and only sees Object and not the correct event type anymore.

I don't know why that's the case or how the best solution looks like. I'm wondering if this change was necessary.

[akarnokd]

Can't you specify the type argument when using compose?

.compose(Transformers.<T>takeWhileViewAttachedObservable(presenter))

Otherwise, if you read the discussion the former non-variant version was problematic under Java 8.

[vRallev]

That doesn't work in Kotlin (at least I didn't find a way). And if I try to do this in the Java 8 code after applying my change to the method signature, then that doesn't work either.

[vRallev]

My bad, I missed the correct syntax, then it works in Kotlin

.compose(Transformers.takeWhileViewAttachedObservable<String>(presenter))

So the situation got better for Java, but worse for Kotlin.

[akarnokd]

It is due to how type inference and type-variance is implemented in Java and Kotlin. I don't know if they can interoperate on this one but seems explicit typing still allows fixing the ambiguities.

However, since you are in Kotlin, you can define an extension method with the old syntax and avoid specifying type arguments manually.

[vRallev]

Right, that's a great idea. Thanks!