In our DataAccessUtils helper, requiredSingleResult and requiredUniqueResult differ in their nullability declarations. There is no good reason for this; either both of them need to declare a non-null return value or both have to expect null values in their input collections.
#20099 Introduce null-safety of Spring Framework API
Indeed, assuming null elements in the input Collection, we'd have to declare requiredUniqueResult as @Nullable. Or we'd turn it around and leniently assume non-null values in the input collections for those particular methods, even for requiredSingleResult... covering that expectation in the javadoc. The non-null declaration then pragmatically means "never null except when you unexpectedly violate the non-null assumptions for the elements in the input collection".
Unfortunately we can't formally express a non-null expectation for collection elements at this point. So any code interacting with a Collection is bound to deal with unclear nullability. For JdbcTemplate, we can derive the nullability assumption from the original RowMapper callback that populates such an internal collection. However, for DataAccessUtils, we are being given a Collection instance by the user which we have to make a general assumption about.
In practice, it'd be useful to apply DataAccessUtils.requiredUniqueResult to the JdbcTemplate.query variants that return a List - or any similarly structured data access operations -, arriving at a non-null declared reference for a single object if you know that the original collection will never have null elements...
I've turned DataAccessUtils.requiredSingleResult to a non-null expectation (aligned with requiredUniqueResult), allowing for convenient applicability in user code where you typically expect a non-null result. For framework purposes, we're using a nullableSingleResult method with the specific nullability semantics that we get out of a general RowMapper callback now.