We backported various refinements on null-safety i...

# spring

[sdeleuze]

We backported various refinements on null-safety in Spring Framework 6.1.6-SNAPSHOT version based on null-safety mismatches found by enabling https://github.com/uber/NullAway in the upcoming Spring Framework 6.2. There are expected to be all valid changes, but that may introduces breaking changes for people using -Xjsr305=strict. I would welcome feedback from people here by upgrading locally your Spring Boot 3.2 apps to Spring Framework 6.1.6-SNAPSHOT (via ext["spring-framework.version"]= "6.1.6-SNAPSHOT" and maven { url '<https://repo.spring.io/snapshot>' } in your Gradle build for example).

I would like to check how much breaking are those changes for Kotlin developers, and if the gains in term of correctness are worth doing most of those changes in 6.1, or if we should revert some of those changes. Usually, the errors were missing @Nullable annotations on the implementation while present in the interface. The main interface we changed is SimpleJdbcCallOperations.

Please test if you can and let me know how it goes.

[Robert Jaros]

What breaking changes would that be? Compile time? Runtime?

[sdeleuze]

Compile time

[sdeleuze]

Like a return value previously non-nullable now nullable.

[sdeleuze]

Not in a lot of popular use cases so I suspect that's ok-ish but I would value real world feedback.

[Robert Jaros]

I've checked a few of my projects. No problems.