Null Safety in Java with JSpecify and NullAway
summary
Shows a concrete migration: add org.jspecify:jspecify:1.0.0 and enable JSpecify + NullAway (as an Error Prone plugin) to turn nullness warnings into compilation errors, catching missing checks early; Spring Framework annotation sweep finds ~80–90% of type usages are non-null by default so packages use a package-level non-null default and only mark nullable cases; Kotlin 2.1 treats JSpecify mismatches as errors; lazy Spring‑initialized fields need suppressions like newway.init for now, and the build-time checks successfully break CI on null-safety violations.
AI-written summary · about
chapters (19)
- 0:00Null safety in Java
- 2:33Problem with implicit nullness
- 3:16Introducing JSpecify
- 5:25Adding JSpecify dependencies
- 6:07Annotating with @NonNull and @Nullable
- 7:08Why Optional fails
- 9:37JSpecify versus other annotations
- 11:23Setting default nullness
- 13:52JSpecify syntax quirks
- 16:44Enforcing with NullAway
- 18:54Handling null paths
- 20:20Advanced generics and arrays
- 22:10Kotlin interoperability
- 26:07Spring Framework null safety
- 31:33Lazy initialization
- 34:24Spring Boot 4 null-safe APIs
- 36:51Benefits of annotations
- 37:55Future of null safety in JDK
- 39:59Contributing to NullAway and JSpecify
related talks
01h 00mNull Safety in Spring Applications 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
52mPreventing null pointer exceptions at compile time
44mThe long good-bye to NPE
43mIdiomatic Interop