Hacker News Reader

Comment by moss2 | Hacker News Reader

>In Java, there’s no way to know whether a variable is null.

What? What about `foo == null`?

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.

Just a note, Scala 3 has an optional compiler flag to remove null from the type system meaning String can’t contain an NPE.

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.

The author means not knowing it at compile-time. The expression you mention must be evaluated at runtime.

In practice, there are plenty of static analysis programs that will give you the same thing at compile time with @NonNull and similar annotations.

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.

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