This commit deprecates ListenableFuture in favor of CompletableFuture.
ListenableFuture was introduced in Spring Framework 4.0, when
CompletableFuture was not yet available. Spring now requires JDK 17, so
having our own type no longer seems necessary.
Major changes in this commit include:
- Deprecation of ListenableFuture and related types
(ListenableFutureCallback, SettableListenableFuture, etc.)
- Deprecation of AsyncListenableTaskExecutor in favor of default methods
in AsyncTaskExecutor (submitCompletable).
- AsyncHandlerMethodReturnValueHandler now has toCompletableFuture
instead of toListenableFuture.
- WebSocketClient now has execute methods, which do the same as
doHandshake, but return CompletableFutures (cf. the reactive
WebSocketClient).
All other changes
- add an overloaded method that takes a CompletableFuture parameter
instead of ListenableFuture, and/or
- add a method with a 'Async' suffix that returns a CompletableFuture
instead of a ListenableFuture (connectAsync, sendAsync).
Closes gh-27780
SockJsServiceRegistration#setSupressCors name contains a typo. It is
now deprecated in favor of a correctly spelled method, setSuppressCors.
See gh-28853
This commit deprecates all methods in org.springframework.scheduling
that use
- Date, in favor of variants that take an Instant.
- long & TimeUnit, in favor of variants that take a Duration.
Closes: gh-28714
Includes deprecation of NestedServletException, whereas NestedCheckedException and NestedRuntimeException remain as base classes with several convenience methods.
Closes gh-25162
A static nested class does not keep an implicit reference to its
enclosing instance.
This prevents a common cause of memory leaks and uses less memory per
instance of the class.
Closes gh-28433
This commit contains changes made because of the introduction of
HttpStatusCode. In general, methods that used to return a HttpStatus
now return HttpStatusCode instead, and methods that returned raw status
codes are now deprecated.
See gh-28214
Where unfeasible, this commit adds inline comments to explain why
try-with-resources must not be used in certain scenarios. The purpose
of the comments is to avoid accidental conversion to try-with-resources
at a later date.
Closes gh-27823
