How Project Valhalla And JSpecify Can Kill NPEs
NullPointerExceptions (NPEs) are a common source of frustration for Java developers. These occur when a piece of code tries to access or modify a reference in memory that is null, resulting in a runtime exception.
Project Valhalla and JSpecify are two initiatives by the Java community that aim to address this issue and significantly reduce the occurrence of NPEs.
Project Valhalla
Project Valhalla is an experimental OpenJDK project that aims to explore and prototype advanced Java virtual machine (JVM) and language features such as value types, specialized generics, and enhanced nullibility tracking. One of the key goals of Project Valhalla is to provide better support for non-nullable reference types, which can help prevent NPEs.
With Project Valhalla, developers can define reference types that cannot be null, and the compiler can enforce these constraints at compile time. This can greatly reduce the likelihood of NPEs, as the compiler will catch potential null pointer dereferences before they happen.
JSpecify
JSpecify is an annotation-based type system for Java that allows developers to specify nullibility constraints on method parameters, return values, and fields. By using JSpecify annotations, developers can communicate to both humans and tools about the nullibility expectations for their code.
With JSpecify, developers can annotate their code to explicitly indicate whether a value can be null or not, and the Java compiler and static analysis tools can use this information to detect potential NPEs more effectively. By making nullibility constraints explicit, JSpecify helps make code more resilient against NPEs.
Conclusion
Project Valhalla and JSpecify are two promising initiatives in the Java community that can potentially revolutionize the way developers approach nullibility and NPEs. By providing better support for non-nullable reference types and allowing developers to communicate nullibility constraints explicitly, these projects can help kill NPEs and make Java code more robust and reliable.
Why not make strict reference types null checks a compiler flag that has a long migration period. Like in a few years it's on by default and in another couple years it's permanent. And for lagacy libraries you could specify that they are excluded from the checks.
null.equals(null) would yield true but won't work. My workaround could be creating a singleton object Nil for that Nil.equals(Nil) yields true. It's too control about the subject.
What about the interaction between null and generics?
Hey, I'm glad to have come across your channel! Any chance you can make some videos to talk more about java in general? There are many amateur java developers who would really like to hear more explanatory coverage of java's features.
Very happy to hear Primitive classes were phased out – together with records and value (aka inline) types that would've been too many combinations. Whereas value-types and null-awareness: that sounds like an awesome combo!
I'm glad they're being so careful about this. Also, Joda-time is a great example to follow.
value types should be not null-able as default and compiler should check for it