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

[spring-projects-issues]

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:

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

Referenced from: commits 3f32f72, db69a08

[spring-projects-issues]

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