6 ms·

>In Java, there’s no way to know whether a variable is null. What? What about `foo == null`?

• _han 4y ago
  The author means not knowing it at compile-time. The expression you mention must be evaluated at runtime.
  • kaba0 4y ago
    In practice, there are plenty of static analysis programs that will give you the same thing at compile time with @NonNull and similar annotations.
    • 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.
          • 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.
          • 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).
• lf-non 4y ago
  They don't mean checking at runtime. Looking at a method/property signature it should be explicitly and unambiguously clear whether or not null is an acceptable value - but in java there is no way to enforce this.
• mcv 4y ago
  The issue isn't so much whether it is null, but whether it can be null. Because if it can be null, you have to check whether it is null before you can actually do anything with it. That adds a lot of null-checking boilerplate to your code. If instead the compiler can guarantee that a value will never be null, then you don't have to check, leading to cleaner code. Scala does this with the Option type, Typescript by forcing you to declare a type as `string|null` if it can be null. These sort of things make your code safer and cleaner.
  • kaba0 4y ago
    Just a note, Scala 3 has an optional compiler flag to remove null from the type system meaning String can’t contain an NPE.