It could easily keep the existing methods but switch to using a Supplier
and method references.
Comment From: wilkinsona
Given the existing configure(T)
method, I can't see much benefit to a Supplier
-based approach. To avoid using reflection by default, we could change build()
to the following:
public ThreadPoolTaskExecutor build() {
return configure(new ThreadPoolTaskExecutor());
}
This would remove the use of reflection in the code path driven by TaskExecutionAutoConfiguration
. Anyone using TaskExecutorBuilder
themselves can make a similar change and call configure(new T())
rather than build(Class<T>)
.
Comment From: dsyer
Makes sense I think. Just one possible snag: TheadPoolTaskExecutor
is BeanNameAware
and InitializingBean
and DisposableBean
. We might need to take care of those callbacks as well (although I can't see that they are being called right now)?
Comment From: wilkinsona
If you want those callbacks to be invoked, the expectation is that the instance that's built or configured by TaskExecutorBuilder
is defined as a @Bean
as we do in TaskExecutionAutoConfiguration
.