In addition to our general compatibility effort in #23443, we are going to explore first-class configuration options for virtual threads: e.g. a virtualThreads flag on SimpleAsyncTaskExecutor or a similar dedicated virtual-thread TaskExecutor implementation with thread naming and concurrency throttle support.
We may also introduce virtual thread flags in places where we currently use a SimpleAsyncTaskExecutor by default, such as in DefaultMessageListenerContainer. These facilities can then conveniently be configured for virtual threads on their own (not having to pass a custom ´Executor` for it) and possibly also as part of a wider-ranging virtual thread setup in Spring Boot 3.2.
In contrast to #23443, this effort will require some level of building against JDK 21, at least for the spring-core module which is likely to centralize the foundational configuration pieces for virtual threads. All other modules would just delegate to those classes/methods on an as-needed basis, without incurring any JDK 21 build requirements or defensive mechanisms for running on JDK 17-20 themselves.
Comment From: jhoeller
A convenient setVirtualThreads(true) call on SimpleAsyncTaskExecutor turns out to be a straightforward option for bean-style configuration. The concurrency throttle and the thread naming in SimpleAsyncTaskExecutor is very applicable to virtual threads as well, so it makes sense to combine those capabilities.
In places where that common executor is used by default, it is easy enough to pass in a specifically configured SimpleAsyncTaskExecutor with a virtual thread setup already. A dedicated virtualThreads flag next to an existing taskExecutor property in such places seems a bit convoluted - next to all the non-thread-related configuration options that we have there already (e.g. on DefaultMessageListenerContainer).
In addition, a focused virtual-threads-based executor variant for programmatic use seems attractive as well, in particular for explicitly starting virtual threads from JDK 17 based code (in certain code paths) in other parts of the portfolio, without having to compile against JDK 21 in those places. A single such delegate at spring-core level with support for custom thread naming could be all that we need here.
Comment From: kmandalas
@jhoeller based on https://openjdk.org/jeps/444 which recommends "Do not pool virtual threads", the new configuration options will be applicable only to SimpleAsyncTaskExecutor (and not the ThreadPoolTaskExecutor for example)?
Comment From: jhoeller
Indeed, those options will only be available on SimpleAsyncTaskExecutor and the new VirtualThreadTaskExecutor. We recommend to keep using platform threads for ThreadPoolTaskExecutor and ThreadPoolTaskScheduler, even if technically they can be configured with a virtual ThreadFactory.