Null Safety with JSpecify (Boot 4)

Spring Framework 7 adopts JSpecify for nullability. Use org.jspecify.annotations for new code and migrate away from the older Spring nullability annotations at module boundaries.

Mark packages and annotate exceptions

@NullMarked
package com.example.orders;

import org.jspecify.annotations.NullMarked;

Inside a null-marked package, types are non-null by default. Annotate only genuine exceptions:

@Nullable
Order findActive(String customerEmail) { ... }

List<@Nullable String> namesWithGaps; // non-null list, nullable elements
@Nullable List<String> maybeNoList;   // nullable list, non-null elements

Use Object @Nullable [] for a nullable array and @Nullable Object[] for a non-null array whose elements may be null. Add the JSpecify dependency through the Boot dependency management.

JSpecify is metadata. IntelliJ can inspect it, while NullAway with JSpecifyMode=true can enforce the contract during compilation. Kotlin consumes the annotations as real nullability.

Gotchas

• Agent uses org.springframework.lang.Nullable in new Framework 7 code - prefer JSpecify.
• Agent annotates every parameter with @NonNull - use package-level @NullMarked and mark exceptions.
• Agent writes @Nullable List<String> for nullable elements - use List<@Nullable String>.
• Agent puts @Nullable on the wrong side of an array type - distinguish nullable arrays from nullable elements.
• Agent expects annotations alone to fail the build - add NullAway or enable IDE inspections.
• Agent forgets package-info.java - without @NullMarked, most checks remain unknown.
• Agent mixes JSpecify and legacy Spring annotations in one module - migrate the module consistently.