You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update code to prepare for nullness annotations in rxjava3 and Guava.
(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 will be changing in Kotlin 1.7:
https://github.com/JetBrains/kotlin/blob/05822c59b516b6d252bd6d27e9032e660e15b625/core/compiler.common.jvm/src/org/jetbrains/kotlin/load/java/JavaNullabilityAnnotationSettings.kt#L42-L46
We can preview the behavior by passing
[email protected]:strict:
https://kotlinlang.org/docs/java-interop.html#nullability-annotations
We additionally set -Xtype-enhancement-improvements-strict-mode so that
the Kotlin compiler looks at type-use annotations on type arguments,
type parameters, etc.:
https://kotlinlang.org/docs/java-interop.html#annotating-type-arguments-and-type-parameters
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, the update is to change an unnecessarily
nullable type to be non-nullable. Finally, I removed a `value == null`
check in `RxMaybeCoroutine.onCompleted` that the compiler now identifies
as unnecessary. (I can keep it if you'd prefer.)
Guava's current nullness annotations likewise don't yet trigger Kotlin
compile errors. However, Guava did recently remove the misleading
`@Nullable` annotation from the parameter of `FutureCallback.onSuccess`:
Before:
https://github.com/google/guava/blob/v28.0/guava/src/com/google/common/util/concurrent/FutureCallback.java#L34
After:
https://github.com/google/guava/blob/v31.0.1/guava/src/com/google/common/util/concurrent/FutureCallback.java#L35
That means that a `FutureCallback<T>` can now implement `onSuccess(T)`
instead of `onSuccess(T?)`. And with a future change to Guava, it will
_have to_.
When I updated this project from Guava 28.0 to Guava 31.0.1, I found
that that pulled in a newer version of the Checker Framework nullness
annotations. That version was build with a newer version of Gradle, so
it generates Gradle module metadata:
https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html
That metadata declares that the Checker Framework annotations require
Java 1.8. Even the old version had in fact required Java 1.8 -- and so
had even the old version of Guava -- just without having that encoded in
its metadata. So I fixed this by setting targetCompatibility and
sourceCompatibility to 1.8 for kotlinx-coroutines-guava, too.
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.
// Recognize rxjava3 nullness annotations even before that becomes the default (which will happen in 1.7): https://kotlinlang.org/docs/java-interop.html#nullability-annotations
0 commit comments