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.
Comment From: leikingo
Hi.
I stumbled upon this issue and esp. 4c7735016b2edb6766261c2882e17ff3662d607f 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)
Comment From: 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