[hibikir]

I have worked at over a dozen companies where they were using Java. I have yet to see one where null checks and error handling thanks to said null checks doesn't occupy a significant percentage of the application. Maybe I am unlucky, or maybe you've done so much Java now you don't even read the null checks and attached error handling everywhere.

[kaba0]

Maybe our definition of significant percentage is different, but I honestly don’t find it too much.

A notable exception is some kind of generated objects, from say, wsdls getting transformed to different dtos, but in this case MapStruct is a godsend, and is overall less error-prone than doing it even in a null-safe language. (Manually copying fields won’t tell you if a new field is added that should also be copied, for example).

[vips7L]

I think you’re just unlucky. Having compiler enforced null checking does not reduce the amount of nulls you need to check. They will still be everywhere and you will still have instances where people will not check null from a nullable function with !! because they believe their input won’t give them null back.

[Tainnor]

> Having compiler enforced null checking does not reduce the amount of nulls you need to check.

If a function in a null-safe language is declared to return "String", then it signals that, effectively, you don't have to check for null. So, yes, compiler-enforced null safety does reduce the amount of nulls you need to check.

The trick, of course, is to not make everything nullable, but as few things as possible.

In Kotlin, of course, this is only true up to the point where Java interop might interfere with it (because Kotlin might infer a Java return type to be non-nullable when it's in fact nullable).