Stop referring to "JDK 8" features in documentation

See gh-36310
This commit is contained in:
Sam Brannen
2026-02-12 12:27:51 +01:00
parent 1703388074
commit cb8ed43be1
11 changed files with 29 additions and 27 deletions
@@ -533,8 +533,7 @@ that returns a value:
----
TIP: `@Async` methods may not only declare a regular `java.util.concurrent.Future` return
type but also Spring's `org.springframework.util.concurrent.ListenableFuture` or, as of
Spring 4.2, JDK 8's `java.util.concurrent.CompletableFuture`, for richer interaction with
type but also `java.util.concurrent.CompletableFuture`, for richer interaction with
the asynchronous task and for immediate composition with further processing steps.
You can not use `@Async` in conjunction with lifecycle callbacks such as `@PostConstruct`.
@@ -13,9 +13,9 @@ the same xref:web/webflux/reactive-spring.adoc[Reactive Core] foundation.
== Overview
[.small]#xref:web/webmvc-functional.adoc#webmvc-fn-overview[See equivalent in the Servlet stack]#
In WebFlux.fn, an HTTP request is handled with a `HandlerFunction`: a function that takes
In WebFlux.fn, an HTTP request is handled with a `HandlerFunction`: a function that takes a
`ServerRequest` and returns a delayed `ServerResponse` (i.e. `Mono<ServerResponse>`).
Both the request and the response object have immutable contracts that offer JDK 8-friendly
Both the request and the response object have immutable contracts that offer convenient
access to the HTTP request and response.
`HandlerFunction` is the equivalent of the body of a `@RequestMapping` method in the
annotation-based programming model.
@@ -117,7 +117,7 @@ Most applications can run through the WebFlux Java configuration, see xref:web/w
== HandlerFunction
[.small]#xref:web/webmvc-functional.adoc#webmvc-fn-handler-functions[See equivalent in the Servlet stack]#
`ServerRequest` and `ServerResponse` are immutable interfaces that offer JDK 8-friendly
`ServerRequest` and `ServerResponse` are immutable interfaces that offer convenient
access to the HTTP request and response.
Both request and response provide {reactive-streams-site}[Reactive Streams] back pressure
against the body streams.
@@ -15,7 +15,7 @@ the same xref:web/webmvc/mvc-servlet.adoc[DispatcherServlet].
In WebMvc.fn, an HTTP request is handled with a `HandlerFunction`: a function that takes
`ServerRequest` and returns a `ServerResponse`.
Both the request and the response object have immutable contracts that offer JDK 8-friendly
Both the request and the response object have immutable contracts that offer convenient
access to the HTTP request and response.
`HandlerFunction` is the equivalent of the body of a `@RequestMapping` method in the
annotation-based programming model.
@@ -116,7 +116,7 @@ xref:web/webmvc-functional.adoc#webmvc-fn-running[Running a Server].
== HandlerFunction
[.small]#xref:web/webflux-functional.adoc#webflux-fn-handler-functions[See equivalent in the Reactive stack]#
`ServerRequest` and `ServerResponse` are immutable interfaces that offer JDK 8-friendly
`ServerRequest` and `ServerResponse` are immutable interfaces that offer convenient
access to the HTTP request and response, including headers, body, method, and status code.
[[webmvc-fn-request]]
@@ -6,7 +6,7 @@
The next table describes the supported controller method arguments. Reactive types are not supported
for any arguments.
JDK 8's `java.util.Optional` is supported as a method argument in combination with
`java.util.Optional` is supported as a method argument in combination with
annotations that have a `required` attribute (for example, `@RequestParam`, `@RequestHeader`,
and others) and is equivalent to `required=false`.
@@ -40,7 +40,7 @@ import org.springframework.util.StringUtils;
/**
* Formats fields annotated with the {@link DateTimeFormat} annotation using the
* JSR-310 <code>java.time</code> package in JDK 8.
* JSR-310 <code>java.time</code> package.
*
* @author Juergen Hoeller
* @author Sam Brannen
@@ -1,5 +1,5 @@
/**
* Integration with the JSR-310 <code>java.time</code> package in JDK 8.
* Integration with the JSR-310 <code>java.time</code> package.
*/
@NullMarked
package org.springframework.format.datetime.standard;
@@ -49,14 +49,15 @@ public class ForkJoinPoolFactoryBean implements FactoryBean<ForkJoinPool>, Initi
/**
* Set whether to expose JDK 8's 'common' {@link ForkJoinPool}.
* <p>Default is "false", creating a local {@link ForkJoinPool} instance based on the
* {@link #setParallelism "parallelism"}, {@link #setThreadFactory "threadFactory"},
* {@link #setUncaughtExceptionHandler "uncaughtExceptionHandler"} and
* {@link #setAsyncMode "asyncMode"} properties on this FactoryBean.
* <p><b>NOTE:</b> Setting this flag to "true" effectively ignores all other
* Set whether to expose Java's 'common' {@link ForkJoinPool}.
* <p>Default is {@code false} , creating a local {@link ForkJoinPool} instance
* based on the {@link #setParallelism parallelism},
* {@link #setThreadFactory threadFactory},
* {@link #setUncaughtExceptionHandler uncaughtExceptionHandler}, and
* {@link #setAsyncMode asyncMode} properties on this FactoryBean.
* <p><b>NOTE:</b> Setting this flag to {@code true} effectively ignores all other
* properties on this FactoryBean, reusing the shared common JDK {@link ForkJoinPool}
* instead. This is a fine choice on JDK 8 but does remove the application's ability
* instead. This is a fine choice but does remove the application's ability
* to customize ForkJoinPool behavior, in particular the use of custom threads.
* @since 3.2
* @see java.util.concurrent.ForkJoinPool#commonPool()
@@ -147,7 +147,7 @@ public abstract class NumberUtils {
else if (number instanceof BigDecimal bigDecimal) {
bigInt = bigDecimal.toBigInteger();
}
// Effectively analogous to JDK 8's BigInteger.longValueExact()
// Effectively analogous to Java's BigInteger.longValueExact()
if (bigInt != null && (bigInt.compareTo(LONG_MIN) < 0 || bigInt.compareTo(LONG_MAX) > 0)) {
raiseOverflowException(number, targetClass);
}
@@ -133,7 +133,7 @@ class SortedPropertiesTests {
String[] lines = lines(baos);
assertThat(lines).isNotEmpty();
// Leniently match first line due to differences between JDK 8 and JDK 9+.
// Leniently match first line due to potential differences between JDK versions.
String regex = "<\\?xml .*\\?>";
assertThat(lines[0]).matches(regex);
assertThat(lines).filteredOn(line -> !line.matches(regex)).containsExactly( //
@@ -160,10 +160,11 @@ class AnnotationUtilsTests {
assertThat(getAnnotation(bridgeMethod, Order.class)).isNull();
assertThat(findAnnotation(bridgeMethod, Order.class)).isNotNull();
// As of JDK 8, invoking getAnnotation() on a bridge method actually finds an
// annotation on its 'bridged' method [1]; however, the Eclipse compiler does
// not support this [2]. Thus, we effectively ignore the following
// assertion if the test is currently executing within the Eclipse IDE.
// For code compiled with OpenJDK, invoking getAnnotation() on a bridge
// method actually finds an annotation on its 'bridged' method [1]; however,
// the Eclipse compiler does not support this [2]. Thus, we effectively
// ignore the following assertion if the test is currently executing within
// the Eclipse IDE.
//
// [1] https://bugs.openjdk.java.net/browse/JDK-6695379
// [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=495396
@@ -893,10 +893,11 @@ class MergedAnnotationsTests {
assertThat(MergedAnnotations.from(method).get(Order.class).getDistance()).isEqualTo(-1);
assertThat(MergedAnnotations.from(method, SearchStrategy.TYPE_HIERARCHY).get(
Order.class).getDistance()).isEqualTo(0);
// As of JDK 8, invoking getAnnotation() on a bridge method actually finds an
// annotation on its 'bridged' method [1]; however, the Eclipse compiler does
// not support this [2]. Thus, we effectively ignore the following
// assertion if the test is currently executing within the Eclipse IDE.
// For code compiled with OpenJDK, invoking getAnnotation() on a bridge
// method actually finds an annotation on its 'bridged' method [1]; however,
// the Eclipse compiler does not support this [2]. Thus, we effectively
// ignore the following assertion if the test is currently executing within
// the Eclipse IDE.
//
// [1] https://bugs.openjdk.java.net/browse/JDK-6695379
// [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=495396