Prior to this commit, calls to `MimeType` and `MediaType` would create a
significant amount of garbage:
* during startup time, in the static sections of `MimeType` and
`MediaType` when creating well-known types
* at runtime, when parsing media types for content negotiation or
writing known media types as strings in HTTP response headers
This commit does the following:
* Avoid parsing the well-known types and use regular constructors
instead
* Cache types in a simple LRU cache once they've been parsed, since an
application is likely to deal with a limited set of types
* Avoid using `java.util.stream.Stream` in hot code paths
Benchmarks show that a complete revision of the `MimeTypeUtils` parser
is not required, since the LRU cache is enough there.
Closes gh-22340
Prior to this commit, profiling sessions would show that using
`java.util.stream.Stream` in some hot code paths creates significant
garbage.
Where streams aren't really required, this commit turns those snippets
into imperative logic because those are likely to be called once or
multiple times per request.
Closes gh-22341
* pr/22337:
Polish "Fix use CompletableFuture in DeferredResultReturnValueHandlerTest"
Fix use CompletableFuture in DeferredResultReturnValueHandlerTest
This commit improves the message for HttpStatusCodeException so that it
defaults to the HttpStatus reason phrase if a status text is not
provided.
This commit also fixes SimpleClientHttpResponse so that it does not
return null for getStatusText().
Fixed#22162
Prior to this commit, Spring WebFlux function would let
`DecodingException` thrown by codecs bubble up to the web handler level.
Since this exception is not handled by default there, the response would
be turned into a HTTP 500 status.
In the annotation model, `ArgumentResolver` implementations wrap this
exception with a `ServerWebInputException`, which itself extends
`ResponseStatusException`. The latter is supported by the error handling
infrastructure as a HTTP 400 response.
This commit ensures that `DecodingException` instances are properly
wrapped in `ServerWebInputException` at the `ServerRequest` level
directly, thus supporting all setup modes ("standalone" and through the
`DispatcherHandler`).
Fixes#22290
