Hi,
I am migrating my program from Scala to Kotlin. I replaced some functionality (immutable collections etc) with Guava. Obvious problem is a nullability, my Kotlin code is full of exclamation marks. This is not neccessary, Guava uses @Nullable annotations and all nullability info is there.
Problem is explicit/implicit nullable declaration. For Kotlin all Java code is nullable, unless @Nonnull is used. For Guava everything is nonnull, unless @Nullable is used.
So my question: is there a way to tell Kotlin Compiler that some java package is Null Safe? I would like an option to switch Null Safety from explicit to implicit on per package basis.
I know about external Kotlin annotations, but it does not support package wildcards.
Also I know about generics and collections problem (fun File.listFiles(): Array<File?> ). I am not trying to solve this, external Kotlin annotations would be still needed in this case.
Currently, there is no way of providing package-wise nullability information.
Technically, it would be possible to implement, but I suspect that there will be many subtleties.
If you want to make a detailed proposal, please, go ahead.
I mentioned the idea here. I think its pretty common for classes and packages to choose never to return nulls in Java APis; so rather than always assuming everything in java land is nullable and having to provide custom method signatures for every single method on every single class in a package, it would be good to override the default 'nullable' mode on a per package or class basis.
e.g. to make Apache Camel work nicely in Kotlin it’d be great to just map “org.apache.camel.model* = notNull” (in some properties file / XML file discovered on the classpath or something) as pretty much every method on every class in that package (and child packages) use not null APIs.
Then custom method signatures can be provided to override the package/class level rules. (The most specific rule wins - so in the absence of method specific signatures, the class/package level rules win).
Something really simple like this would make a massive difference in Java interop; allowing package/class wildcards to specify not-null (rather than nullable) as the default.