Skip to content

Support for java.util.OptionalInt/Long/Double as @RequestParam #33301

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

Closed
cart-before-horse opened this issue Aug 1, 2024 · 1 comment
Closed
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: declined A suggestion or change that we don't feel we should currently apply

Comments

@cart-before-horse
Copy link

cart-before-horse commented Aug 1, 2024

Affects: 4.1+


Spring supports java8 generic Optional<?> as a request parameter (see #16448 0dc6082).
But there are value-based primitive counterparts:

  • java.util.OptionalInt
  • java.util.OptionalLong
  • java.util.OptionalDouble

which are not supported. For example, simple controller methods like this

@GetMapping
void doSomething(@RequestParam OptionalLong filterId)

require cumbersome fiddling with converters and method argument resolvers.

Is it worth implementing these types as well to get more consistent behavior? Such classes are quite useful especially in conjunction with primitive streams or custom primitive collections (we use fastutils). Their apis usually offer bare primitive types instead of boxed wrappers. Sure, it is possible to get it working without extra config just with generic Optional<BoxedType> and some manual casts here and there, it just feels unnecessary.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Aug 1, 2024
@cart-before-horse cart-before-horse changed the title Support for java.util.OptionalInt/Long/Double Support for java.util.OptionalInt/Long/Double as @RequestParam Aug 1, 2024
@sbrannen sbrannen added in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement labels Aug 2, 2024
@sbrannen sbrannen self-assigned this Aug 2, 2024
@snicoll snicoll removed the type: enhancement A general enhancement label Aug 2, 2024
@sbrannen
Copy link
Member

sbrannen commented Aug 2, 2024

Hi @cart-before-horse,

Congratulations on submitting your first issue for the Spring Framework! 👍

Is it worth implementing these types as well to get more consistent behavior?

Due to the added complexity required to support all Optional variants consistently across the code base, we do not feel it is worth supporting those types.

In light of that, I am closing this issue.

Regards,

Sam

@sbrannen sbrannen closed this as not planned Won't fix, can't repro, duplicate, stale Aug 2, 2024
@sbrannen sbrannen added status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Aug 2, 2024
@snicoll snicoll removed the type: enhancement A general enhancement label Aug 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

No branches or pull requests

4 participants