Overview
JdbcOperations.query(String, ResultSetExtractor<T>) is currently declared as @Nullable.
Tweaking the declaration to:
<T extends @Nullable Object> T query(String sql, ResultSetExtractor<T> rse) throws DataAccessException;
would allow tooling to deduce the nullability of T from the ResultSetExtractor handed into the method.
Comment From: sbrannen
Although the proposed change is supported by JSpecify, it is not yet supported by NullAway.
We have therefore decided to postpone making such changes until the next 7.0 milestone or release candidate.
See Also
- https://github.com/uber/NullAway/issues/1075
- commit b6680422dbc0aebcd46a821f183dce101b5cd411
Comment From: sdeleuze
So your ask perfectly makes sense @odrotbohm, but while supported in JSpecify specification, it is not yet possible to perform such generic method nullness checks with NullAway, either in Spring codebase or our users ones, due to https://github.com/uber/NullAway/issues/1075. We have reached NullAway project lead to ask to raise the priority on the use cases we need, and we hope geting a related fix before Spring Framework 7 GA, but we can't be sure, that's the reason why I have moved this issue to the 7.0.x bucket as blocked.
In the meantime, we can do better than current signature that is enforcing unnecessary checks on the return value nullability. That's why I have created https://github.com/spring-projects/spring-framework/issues/35147 and https://github.com/spring-projects/spring-framework/issues/35146 that will hopefully improve the status quo as of Spring Framework 7 next milestone.
Comment From: sdeleuze
As mentioned in this comment, my @NullUnmarked temporary workaround works pretty badly with Kotlin, so the best option seems to move forward on this issue with the proper idiomatic code, ignore NullAway warnings with @SuppressWarnings("NullAway") // See https://github.com/uber/NullAway/issues/1075 and document the related limitation.
In parallel we collaborate with the NullAway team to help fixing this hopefully before our GA.