Gems

JSpecify nullness design FAQ

As JSpecify is still in early stages, the link you followed has brought you to a draft document, which we are using for ease of editing. In the unspecified future this will become markdown hosted at jspecify.org, and as we update links we will make them into deep-links to the appropriate section (sorry that for now you were brought only to the top).

Project members: please edit at will; comment only if unsure of a change.

Can’t you see that nullness annotations are ugly, and we’d be better off with a String? language feature like Kotlin has?

Yep.

Gems

The Power of Ten – Rules for Developing Safety Critical Code

Author: Gerard J. Holzmann
Institution: NASA/JPL Laboratory for Reliable Software
Location: Pasadena, CA 91109

---

Introduction

Gems

Non-Null vs. Nullable by Default in Java: Industry Trends and Arguments

Background: Java’s Nullability Problem

Java historically treats all object references as potentially null by default – there is no built-in way in the type system to indicate whether a variable can or cannot be null . This implicit “nullable by default” design has led to the infamous NullPointerException (“billion-dollar mistake” as Tony Hoare called it ) when null values aren’t handled properly. For decades, developers had to rely on documentation, runtime checks, or patterns like returning sentinel values/Optional to signal absence of a value .

To improve safety, the Java ecosystem introduced nullability annotations (e.g. @Nullable, @NonNull/@NotNull) and static analysis tools. However, a key question arises: should we assume types are non-nullable by default (requiring explicit annotation of