Refine null-safety with NullAway build-time checks

[sdeleuze]

As discussed with the JSpecify working group, the goal of this issue is to introduce null-safety checks at build-time using NullAway and the related Error Prone Gradle plugin and refine Spring null-safety annotations accordingly.

Unlike #28797, the purpose of this issue is to continue to leverage JSR 305 annotations. That said, such formal build-time checks will likely ease a potential transition to a different null-safety mechanism (JSpecify or at Java platform level) in the future.

See this draft commit that enables those null-checks on spring-core and generates 41 errors that will likely to lead null-safety refinements.

[leikingo]

Hi.
I stumbled upon this issue and esp. 4c77350 for the class org.springframework.util.Assert while trying to get rid of some null warnings in IntelliJ.

Is there a specific reason why for example the method hasText does not have a contract @Contract(null, _ -> fail) ?

I'm often using only hasText for incoming @Nullable strings to ensure a non-null value afterwards, but unfortunately this does not eliminate the warning. Although hasText would also throw an exception in case of null. For now I need to add also notNull or use 'external contract annotations' in IntelliJ. IntelliJ's external annotations are a bit cumbersome, since it is not possible to do it globally (as far as I know at least). It would be great if those @Contract annotations could be added to the remaining Assert methods as well to avoid this in the future. (hopefully they would then also be recognized by IntelliJ)

[sbrannen]

Hi @leikingo,

This issue was closed 6 months ago for 6.2 M1.

Can you please create a new issue to address your concerns about missing @Contract declarations in Assert?

Thanks