alt Hacker NewsIt’s still missing null safety, right? Which means it’s still a hard no for me.
Replies
We have a java monorepo of relatively large size and sophistication, driving our entire fintech, and I haven't seen a NPE for years.
Use NullAway and it basically makes the problem go away. Our application won't build if it detects a potential NPE.
I have a couple 50k+ loc java projects written entirely by LLMs at this point that have never thrown an NPE.
You can either use Kotlin then, or simply use java and nullability annotations, they have good support in both IDEs and analysis tools
Have you tried not returning null or constructing incomplete objects?
It is really not a big deal nowadays, the problem of the same scale as having index out of bounds error (no language has good defence against this, yet it is not a catastrophe).
Nullability annotations + tooling makes this a non-issue in practice.
Really?
Unlike C it is trivial to catch a NullPointerException and confine the crash to the unit of work. And unlike C you are not talking about insanely dangerous pointers, you're just talking about an NPE.
I'll admit it's a hassle when something wasn't initialized properly and then you get a null pointer exception at some unrelated code much later. It's not always easy to debug. Catastrophic? No!
There are a lot of third party tools that can check for null safety and a lot of work is being done to make Java's initialization safer but also a little more flexible, there is
https://openjdk.org/jeps/8303099
and there are all sorts of practical answers. Nulls in Java are low on my list of annoyances, way behind front end programmers who pepper my CSS files with "!important" because they don't know about precedence (though maybe they think my .clazz.clazz.clazz selector is brain dead!)
Any serious project will be using NullAway and annotating everything (or, indeed, using Kotlin).
Otherwise, yeah, you're still in for a world of pain.
The ecosystem has (at long last) standardized on JSpecify (https://jspecify.dev) for nullability annotations. JSpecify allows you to annotate a package or module with `@NullMarked` and your IDE and build (via ErrorProne+NullAway, typically) will check for null safety.
If you develop a library in Java and use it from Kotlin, the built-in Kotlin null-safety will recognize the JSpecify annotations on the library.
Null-restricted types are on the roadmap. See: https://openjdk.org/jeps/8303099