Why is JSpecify considered a breaking change for some Kotlin Spring projects upgrading to Spring Framework 7?

Kotlin's compiler enforces null-safety at compile time, and it does so for Spring's own APIs by reading whichever nullability annotations Spring's method signatures carry - previously Spring's own org.springframework.lang.Nullable/NonNull annotations, now JSpecify's @Nullable/@NonNull in Spring Framework 7.

// if a return type's nullability annotation changes,
// Kotlin's inferred type for it changes too
val user: User = userLookup.findByEmail(email) // was non-null, may now require User?

Two things compound the risk on upgrade. First, the annotation set itself changed, so even a semantically identical @Nullable usage is now read via a different type Kotlin's compiler resolves differently in edge cases. Second, and more consequential, Spring 7 tightened nullability checking to only honor annotations declared directly on a method, no longer inheriting them from an overridden superclass or interface method - so a method that relied on inherited annotations for its nullability contract may now appear unannotated (and therefore platform-typed or defaulted) to Kotlin's compiler. The practical effect is that an upgrade can silently change which Spring API calls Kotlin considers nullable, surfacing as new compiler warnings, new smart-cast failures, or previously safe !! non-null assertions becoming genuinely risky - it is rarely a hard compile error across the board, but it is not a safe, unreviewed drop-in upgrade for a Kotlin codebase either.