The most of java library don’t have the nullable annotations so the kotlin compilator can’t throw error with a possible null.
Will be interesting can add manually the annotations in our project as the extension methods.
When you make the definition, the compiler throw error if you don’t check the null
val a = LibraryClass()
val b = a.fooMethod() //compilation error
Nullability can be often inferred using bytecode inspection or supporting custom annotations.
The ability to support metadata can improve compilation error’s detection, lack of metadata will back to platform type.
This was supported in pre-1.0 versions of the compiler and we dropped the support, because we don’t want the semantics of the code being compiled to depend on optional supporting files.
This choice is absolutely reasonable, however a better management of platform type should be helpful.
Using some kind of extra information leads to:
- IDE proposes right cast to Kotlin type
- IDE/compiler plugin shows a warnig for incorrect use of platform type (similar to Java @NonNull management)
- an external tool can fail build test phase
Managing this use case doesn’t require compiler modification.
But at this moment Kotlin compiler doesn’t complain about not-annotated Java values. So if “optional supporting files” are missing everything will compile anyway, won’t it?
So I think it will be good to return this feature at least on warnings level.