Support java.util.Optional as parameter type in resource methods
Jersey fills in missing optional resource method arguments with 'null'. Dealing with "possibly null" variables can be a bit of an annoyance, so more than often I do
Optional<String> optArg1 = Optional.ofNullable(arg1); Optional<String> optArg2 = Optional.ofNullable(arg2); ...
at the top of my resource methods. This opens up for use of many convenience methods such as map, orElse, orElseThrow, ifPresent etc.
So, request for enhancement: Let Jersey handle java.util.Optional as parameter type in resource methods directly.
- Issue Imported From: https://github.com/jax-rs/api/issues/503
- Original Issue Raised By:@glassfishrobot
- Original Issue Assigned To: @glassfishrobot
@glassfishrobot Commented Reported by aioobe_
@glassfishrobot Commented This issue was imported from java.net JIRA JAX_RS_SPEC-498
The FormParam, QueryParam, etc. when the parameter instance is nullable, should accept Optional<xxx> as a parameter type.
@jakartaee/ee4j-rest-committers Shall we adopt this in 5.0? WDYT?
Better support for Optional<?> is definitely desirable.
Supporting Optional makes sense to me as well.
Jersey should support Optional. @hantsy if you have any use case that does not work, please file a bug on Jersey
@hantsy Feeling in the mood for a PR changing the Spec, API and TCK?
FWIW RESTEasy supports it for annotations like @QueryParam, @FormParam, @HeaderParam, @MatixParam and @CookieParam.
Same for Quarkus REST.
I suggest also supporting it for method return types.
Same for Quarkus REST.
I suggest also supporting it for method return types.
As a method can return any type already, there could exist third party MBW for Optionals already. These will break, if we now replace them with null. How to solve this?
The same is true of parameters via ParamConverter. They can be provided by the system with a lower priority than user providers, but it's fairly likely that either version will do the exact same thing.
Your are correct, we could deal with this using priorities.