Nullability inconsistency in DataAccessUtils requiredSingleResult vs requiredUniqueResult [SPR-16225]

[spring-projects-issues]

Juergen Hoeller opened SPR-16225 and commented

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.

---

Affects: 5.0.1

Issue Links:

• Introduce null-safety of Spring Framework API [SPR-15540] #20099 Introduce null-safety of Spring Framework API

Referenced from: commits b1c657f, 723b2b1

[spring-projects-issues]

Ivan Sopov commented

Currently it seems to be a bug in requiredUniqueResult - it returns null in the following case:

Object requiredUniqueResult = DataAccessUtils.requiredUniqueResult(Arrays.<Object>asList(null, null));
System.out.println(requiredUniqueResult);

[spring-projects-issues]

Ivan Sopov commented

BTW DataAccessUtils.objectResult(Arrays.<Object>asList(null, null), (Class<?>) null) returns null too while this method is not annotated with Nullable.

[spring-projects-issues]

Juergen Hoeller commented

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...

[spring-projects-issues]

Juergen Hoeller commented

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.