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

Revisit java.util.Optional declarations in reactive API signatures [SPR-15576] #20135

Closed
spring-projects-issues opened this issue May 23, 2017 · 1 comment
Assignees
Labels
in: web type: task
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented May 23, 2017

Juergen Hoeller opened SPR-15576 and commented

Our reactive web utilities and in particular core WebFlux APIs tend to use java.util.Optional in their API declarations, in particular for optional return values. Optional usage is highly debatable in general but, as we learned now, in particular not really idiomatic in Kotlin.

Let's revisit this for 5.0 RC2, reducing Optional usage to actual stream-like API purposes.


Affects: 5.0 RC1

Issue Links:

  • #20099 Introduce null-safety of Spring Framework API

Referenced from: commits 3f32f72, db69a08

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 23, 2017

Juergen Hoeller commented

I've pushed a quite comprehensive commit now, avoiding java.util.Optional signatures for simple field access, both on data classes and on configuration artifacts. We still have Optional in use for several retrieval APIs but we do not use it for expressing plain nullability of an underlying field anymore, with the intention to rely on @Nullable and co for such purposes instead (#20099).

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

No branches or pull requests

2 participants