3.x: Breaking API changes

[akarnokd]

This issue collects the API changes proposed for 3.x: unused operators and overloads, mistakes in signatures, etc.

• Remove: Flowable.subscribe(/* 4 args */) with Consumer<? super Subscription> -> 3.x: Various small API changes and removals #6517
• Remove: Observable.subscribe(/* 4 args */) with Consumer<? super Disposable> -> 3.x: Various small API changes and removals #6517
• Change: Completable.blockingGet() signature -> 3.x: Various small API changes and removals #6517
• Change: Maybe.defaultIfEmpty to return Single. -> 3.x: Various small API changes and removals #6517
• Change: X.to() to use dedicated non-generic functional type which then can be implemented by a single class for multiple base types. (3.x: Proposal: ObservableConverter interface and friends #5654) -> 3.x: Merge as() into to() #6514
• Remove: BehaviorSubject.getValues() -> 3.x: remove getValues() from some subjects/processors #6516
• Remove: BehaviorProcessor.getValues() -> 3.x: remove getValues() from some subjects/processors #6516
• Change: Single.toCompletable to Single.ignoreElement to be consistent with the other types. -> 3.x: Various small API changes and removals #6517
• Remove: AsyncSubject.getValues() -> 3.x: remove getValues() from some subjects/processors #6516
• Remove: AsyncProcessor.getValues() -> 3.x: remove getValues() from some subjects/processors #6516

[ZacSweers]

I'd like to propose making takeUntil and similar variants take a Maybe. The contract is that it takes until the first emission, which is the same contract as a Maybe.

[JakeWharton]

But why? A Single seems more appropriate contract-wise, but at that point I'd generalize it back to Observable which already exists. The need for those overloads is actually a need for polymorphic stream types instead.

…

On Tue, Oct 3, 2017 at 5:30 AM Zac Sweers ***@***.***> wrote: I'd like to propose making takeUntil and similar variants take a Maybe. The contract is that it takes until the first emission, which is the same contract as a Maybe. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5622 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEERrIqc6C7UuvAoQI57Iap-Evhe9xks5sof67gaJpZM4Pj9aM> .

[ZacSweers]

I guess it depends. Sometimes you takeUntil() something that may or may not actually emit, like many lifecycle handling patterns do

[JakeWharton]

But single isn't required to emit.

…

On Tue, Oct 3, 2017 at 5:15 PM Zac Sweers ***@***.***> wrote: I guess it depends. Sometimes you takeUntil() something that may or may not actually emit, like many lifecycle handling patterns do — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5622 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEEa77DEhI-gYqHRXDoLsH2myadDpHks5soqP9gaJpZM4Pj9aM> .

[ZacSweers]

I suppose this is true, if the source stream completes it just disposes the single?

[artem-zinnatullin]

If we decide to keep target version #5620 lower than Java 8 then:

• Would be great to remove throws Exception from io.reactivex.functions.Function#apply() method.

else

• Would be great to remove own io.reactivex.functions.Function and replace it with java.util.function.Function

Sounds good?

[akarnokd]

@artem-zinnatullin Why? Adding the throws Exception was well worth the effort. In fact, the idea was to make it throws Throwable in v3. Btw, the topic warrants its own issue/discussion.

[artem-zinnatullin]

Ah damn checked exceptions. @akarnokd, you're right of course.

For rx chains it's good that Function declares exception and probably should declare Throwable, the use case I was dealing with today is when in our Java code we needed to call function.apply() and had to wrap it in a try-catch. Kotlin 😿

[akarnokd]

• Change: Single.toCompletable to Single.ignoreElement to be consistent with the other types.

[JakeWharton]

Isn't that just a new overload and deprecation that can be done as part of 2.x?

[akarnokd]

Well, the alias could be added to 2.x but then toCompletable should not be in 3.x. Should we start aliasing and deprecating these types of methods in v2 so that users get better prepared for changes in 3.x?