Hacker News Reader

Comment by kaba0 | Hacker News Reader

Sure, language-support would be better indeed, but in practice the often encountered annotations are supported by every tool, and the only relevant setting is whether everything is nullable by default or nothing is.

View on HN

It's still not enforced by the language itself, so nothing stops a third party library (that you have to integrate) from not using the annotations, and then the unknown nullability exerts a domino effect on your own code, "infecting" it with uncertainty.

TBF that is true for the Java-Kotlin boundary as well. You can use values coming from Java (like results from Android platform calls) as non-nullable if you wish, and it will blow up at runtime. The linter will catch those cases, but it's definitely less than ideal.

That's true, but this much is inevitable. Kotlin can't help that the whole world isn't in Kotlin.

For some of this stuff, there are compiler extensions that allow extra type checking to be added e.g. Google Error-Prone: https://github.com/google/error-prone with stuff like: https://errorprone.info/bugpattern/ReturnMissingNullable.

Doesn't help you with third party libraries, but across an org applying that rule (and others!) typically ensures some consistency.

Bytecode analysis is pretty trivial. I'm not sure if modern tools do it, but figuring out whether that specific bytecode accepts null values or throws NPE with it is not hard (unless bytecode is available in runtime-only and compile-time dependencies contain only interfaces, but that model seems outdated).

Reply on news.ycombinator.com