Nullable definitions for java library

Language Design
1

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.

@Nullable LibraryClass.fooMethod
@Nullable LibraryClass.barMethod

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
1 Like
2

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.

3

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.

1 Like
4

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.

1 Like
5

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.