12 ms·

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 feat

by giords 4y ago

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.

kaba0 4y ago
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.
- V-2 4y ago
  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.
  - vbezhenar 4y ago
    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).
  - craggyjaggy 4y ago
    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.
    - V-2 4y ago
      That's true, but this much is inevitable. Kotlin can't help that the whole world isn't in Kotlin.
  - CHY872 4y ago
    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 https://github.com/google/error-prone with stuff like: https://errorprone.info/bugpattern/ReturnMissingNullable 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.

by giords 4y ago

kaba0 4y ago

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.

V-2 4y ago
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.
- vbezhenar 4y ago
  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).
- craggyjaggy 4y ago
  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.
  - V-2 4y ago
    That's true, but this much is inevitable. Kotlin can't help that the whole world isn't in Kotlin.
- CHY872 4y ago
  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 https://github.com/google/error-prone with stuff like: https://errorprone.info/bugpattern/ReturnMissingNullable 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.