Before this chanhe, these annotations are simply ignored, but they should
preserve flexibility in case of enhanced nullability obtained from
enclosing default qualifier
#KT-20158 Fixed
The problem was that `resolveTypeQualifierAnnotation` actually doesn't
guarantee that `typeQualifierAnnotation` is javax.annotation.NonNull
with argument
It could be just any type qualifier (see the test)
For sake of working without jsr305.jar in the classpath `resolveTypeQualifierAnnotation`
may return javax.annotation.CheckForNull (although the latter is nickname itself)
#KT-19985 Fixed
It was only used for type-related nullability/mutability
annotations and it was necessary to remove them
in the descriptor renderer (duplicating their fqnames there).
At the same time they're only needed for types enhancement
where they can be simply restored from type owners' descriptors
The testData changes are more or less correct: this kind of annotations
is bound both to types themselves and their use because of their targets
- tests and declarations for checkerframework has been moved,
because they only Java 8 targeted
- tests for eclipse annotations has been just copied,
because there are two jars: one for Java 8 and other for earlier versions
Java nullability annotations may generate types that currently are not denotable in Kotlin:
class Java {
void <F> foo(@NotNull F f) {}
}
Type of given value parameter should be not nullable under any substitution:
String/String?/String! because of annotation contract.
NB: Currently there is no full analogues for such types in pure kotlin
Denis Zharkov