Update code to prepare for nullness annotations in rxjava3.

[cpovirk]

(In addition to keeping the code compiling in the future, this change should make some runtime nullness errors impossible.)

rxjava3 nullness annotations don't yet trigger Kotlin compile errors, but that is scheduled to change in Kotlin ~1.7~ 1.8.

We can preview the behavior by passing [email protected]:strict.

We additionally set -Xtype-enhancement-improvements-strict-mode so that the Kotlin compiler looks at type-use annotations on type arguments, type parameters, etc.

Usually, the required update is to restrict a type parameter to non-nullable types, since most rxjava types do not support null type arguments. In a few cases, other changes are required.

I should warn you that I have very little understanding of coroutines and of this library. I'm here because we're seeing compile errors inside Google as we work to improve how we handle Kotlin-Java interoperability, and these changes looked like they might be the right fixes. Sorry for any mistakes.

[cpovirk]

Thanks for the quick response. I should have thought to look for history, and sorry for getting distracted by some build issues and not reading the documentation about the branch to work on, etc. :(

I will rebase, split the Guava change out, read some more docs, see if I can find some more background on #2630, and get back to you -- hopefully later this week, but I have overcommitted myself a bit.

[dkhalanskyjb]

Hey, no worries. The history for this is not that easy to find publically, I was simply describing the current state of things. Also, where I'm from, there are public holidays at the end of this week, so I wouldn't be able to respond until Monday anyway.

[cpovirk]

OK, 6 months later, I finally made some time to try to understand things instead of blindly changing ?s :) And yes, all I needed to do was make the RxMaybe change you'd suggested....

Bookkeeping:

• This is now rebased on develop.
• The Guava-related changes were submitted separately in #3026, leaving only the rxjava3-specific changes in this PR.
• This still passes JDK_16=$HOME/jdk1.6.0_45 ./gradlew assemble jvmTest (and also the tests of our rxjava3 users inside Google).

That leaves only(?) the whole question of whether to make breaking changes now at all, as discussed in the other thread.

[cpovirk]

I realized that I never hit "Re-request review."

Again, though, I know you'd already indicated that you probably wouldn't merge this PR anytime soon (possibly never, in fact :)), so I'm hitting the button just in case you were waiting on me to do that. I think I've addressed the smaller comments, leaving only the big "Should we do this at all?" question. And as I said above, I expect to be able to patch Google's local copy of kotlinx.coroutines if you don't want to merge this.

[qwwdfsad]

Hi!

We are not yet decided what to do. As soon as we merge #3324 (which is blocked by 1.7.0 regression, so we are waiting for 1.7.10) where definitely-non-nullable types are available, we'll start investigating the compatibility story, that mostly lies within Java interop and flexible types. We'll figure the final shape out before 1.8.0 where Rx3 annotations are strict. We do not have any preferences between generic parameter upper bound and & Any on receivers, we'll just pick the one that implies the least number of potentially source-breaking changes

[qwwdfsad]

Superseded by https://github.com/Kotlin/kotlinx.coroutines/pull/3393