Use `@NullUnmarked` and `@NonNull` where relevant on generic methods

[sdeleuze]

Overview

As a workaround for #34911 that we can't support yet due to a NullAway temporary limitation, we should turn declarations like this one in JdbcOperations:

<T> @Nullable T query(String sql, ResultSetExtractor<T> rse) throws DataAccessException;

Into the following in order to keep unspecified nullness for the generic type and return value as we are not yet able to check this use case correctly for Spring Framework code or usage within Spring portfolio or user code with NullAway:

@NullUnmarked // Workaround for https://github.com/uber/NullAway/issues/1075
<T> T query(@NonNull String sql, @NonNull ResultSetExtractor<T> rse) throws DataAccessException;

Similar patterns in the Spring Framework codebase should be updated as well.

Once the related NullAway issue has been fixed, this workaround will be replaced (hopefully before Spring Framework 7 GA) by the idiomatic version via #34911:

<T extends @Nullable Object> T query(String sql, ResultSetExtractor<T> rse) throws DataAccessException;

Related Issues

• Specify flexible generics nullness in spring-jdbc #34911
• Declare flexible generic type nullability where relevant #35146

[sdeleuze]

Kotlin inference seems to work pretty badly with @NullUnmarked, so I am closing this issue as not planned, and move forward on #34911 with @SuppressWarnings("NullAway") // See https://github.com/uber/NullAway/issues/1075 when required (+ related documentation for our users).