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.