Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Nov 22, 2017 · 4 comments
Assignees
Labels
in: data type: bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Nov 22, 2017

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:

  • #20099 Introduce null-safety of Spring Framework API

Referenced from: commits b1c657f, 723b2b1

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 22, 2017

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 22, 2017

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 22, 2017

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 26, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data type: bug
Projects
None yet
Development

No branches or pull requests

2 participants