Juergen Hoeller

We aim for tested compatibility with virtual threads in Spring Framework 6.1, against our current programming model. This is in preparation for Project Loom becoming a regular JVM feature but...

Indeed, we expect Virtual Threads to become GA in JDK 21 now: https://openjdk.org/jeps/444 While our baseline will remain at JDK 17 level, we are considering a JDK 21 upgrade for...

We consider our virtual threads efforts as complete at the core framework level now. We expect some follow-up steps based on feedback, possibly before 6.1 GA but certainly in the...

On a related note, we are planning a broader revision of `spring-jms` in 6.2: see #32501, #26840, #22999. While we may be able to address testability as well, I am...

@wilkinsona for 6.1.7, is there anything you'd expect the core container to do here specifically, beyond the general target type support that it has already? I'm afraid there is not...

To summarize our current understanding here: The best we have on offer at the moment is `resolveNamedBean(Class)` as an alternative to `DependencyDescriptor`-based `resolveDependency` for whenever there is just a Class...

For listener recovery, it is indeed recommendable to configure the message listener containers with the target ConnectionFactory directly, letting them use one Connection per listener container. It's a tradeoff with...

I'm afraid there is not much we can do about this on Spring's side since those annotation checks are performed by AspectJ itself which focuses on the concrete class to...

Reopening again after re-reading the details and noticing that the AspectJ compiler does seem to behave differently there. We should investigate how it does that, maybe we can imitate that...

The problem here is the starting of a new thread in `@PostConstruct` which is conceptually a variant of `InitializingBean.afterPropertiesSet`, only really meant to validate configuration state before publishing the bean...