Null Safety in Spring Applications With JSpecify and NullAway
summary
JSpecify 1.0 annotations plus NullAway + ErrorProne enforce null-safety at compile time, turning IDE warnings into failing Gradle builds; Kotlin 2.1 natively reads JSpecify so Java libraries become idiomatic for Kotlin. Spring migrates APIs (observed split 90% non-null 10% nullable) and bundles JSpecify in Spring Framework 7 / Spring Boot 4, uses a Nullness runtime enum, and recommends NullAway configuration (Java 22 javac, Java 17 release target). Lazy-initialized fields use suppressions like NullAway.Init.
AI-written summary · about
chapters (11)
- 0:00Null safety challenges in Java
- 4:54JSpecify annotations for null safety
- 13:23JSpecify vs other nullable solutions
- 20:51NullAway build-time enforcement
- 30:01JSpecify beyond Spring
- 38:52Spring 7 runtime null checks
- 44:51Null safety for lazy initialization
- 47:17Spring Boot 4 null-safe APIs
- 50:49Null safety as zero-cost abstraction
- 53:36Future of Java null safety
- 55:43Q&A
related talks
41mNull Safety in Java with JSpecify and NullAway
48mNull-safe applications with Spring Boot 4
36mJSpecify: Getting Rid of the Billion-Dollar Mistake in Java for Good This Time
53mNulls are dead
36mRetrofitting Null-Safety into Java
44mThe long good-bye to NPE
52mPreventing null pointer exceptions at compile time
01h 14mSpring I/O 2025 Keynote