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.