Hacker News Reader

Comment by giords | Hacker News Reader

Too bad you need external tools anda lot of boilerplate that you must remember to enforce to achieve this, because it's an after thought and not a language feature.

And there's 7-8 different annotations to mark nullability, all slightly different in some detail.

It's a bloody and messy hell.

View on HN

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.

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