Why Java Developers Should Stop Treating Null as a Minor Issue – JSpecify Turns NPEs into Enforceable Contracts

Null is not a minor bug, it's a missing contract

Many Java developers have become desensitized to NullPointerException; they simply add a null check after an error appears. With AI‑assisted coding, relying on undocumented null assumptions becomes riskier because the AI cannot infer whether a field is required or optional.

JSpecify introduces explicit nullability annotations

JSpecify defines a small set of annotations that make a type’s nullability explicit in the code: @Nullable – the value may be null @NonNull – the value must not be null @NullMarked – unannotated types in the scope are treated as non‑null by default @NullUnmarked – restores the default rule inside a @NullMarked scope

When a package is annotated with @NullMarked, a declaration such as String name is understood to be non‑null, and only @Nullable String nickname indicates a possible null.

Spring Framework 7 adopts JSpecify

Spring 7’s documentation states that the framework now uses JSpecify annotations for API, field, and type nullability and recommends the same for the Spring ecosystem. Earlier Spring annotations ( org.springframework.lang.Nullable, NonNull, NonNullApi, NonNullFields) are being replaced by JSpecify, signalling that null‑safety is moving from personal habit to a framework‑level contract.

Why null contracts matter in the AI era

AI code generators can follow context but cannot guess implicit null contracts. If an API returns User, the AI may assume a user is always present; if it returns @Nullable User, the generator is forced to handle the absent case, and static‑analysis tools can warn at compile time instead of at runtime.

Practical steps to adopt JSpecify

Add nullability annotations to public APIs, service interfaces, DTOs, and repository return types.

Introduce @NullMarked on new packages rather than retrofitting the whole codebase.

Mark potentially null query results, cache reads, or Map#get returns with @Nullable.

Integrate IDE support or tools such as NullAway to surface violations before commit.

When overriding methods, copy the nullability semantics to avoid silently changing the contract.

The goal is not to add more annotations for their own sake, but to reduce guesswork for both developers and AI assistants.

Optional is not a universal replacement

While Optional is useful for indicating a possibly missing return value, it does not cover null contracts for fields, parameters, collection elements, array elements, or third‑party APIs. JSpecify addresses the lower‑level question of whether a particular type usage permits null, and the two approaches complement each other.

Conclusion

As AI writes more code, Java developers must treat null as an explicit contract rather than a “just add a check” problem. Clear nullability contracts—expressed with JSpecify—make code readable, verifiable, and safe for both humans and machines.