Otherwise behavior might change because enhancement may force computation
for other type parameters in cases like:
class A<X extends Y, Y extends X> {}
See the test:
org.jetbrains.kotlin.checkers.DiagnosticsTestGenerated.Tests.J_k#testRecursiveRawUpperBound3
They are hardcoded to avoid having dependency from android.jar on
our annotations' jar with UnderMigration.
Even while it could be a compile-only dependency we need to make sure
that annotated types are read properly without RecentlyNonNull/RecentlyNullable
in the classpath
#KT-24278 Fixed
We are migrating Guava to use these annotations rather than jsr305's
@Nullable. We can't use the Checker Framework's _@Nullable_ yet because
we promise compatibility with Java 7, which doesn't support type
annotations. This is related to but distinct from
https://youtrack.jetbrains.com/issue/KT-21408, which is about a
different jsr305 annotation we use, @ParametersAreNonnullByDefault.
I've also updated some docs to mention Kotlin's existing support for the
Checker Framework _@NonNull_.
Victor Petukhov