The other day I was using org.springframework.scheduling.concurrent.ThreadPo olTaskExecutor as a Spring entry point to java.util.concurrent. This class "allows for configuring a JDK 1.5 java.util.concurrent.ThreadPoolExecutor in bean style" (JavaDocs).
This class wraps and delegates-to an instance of java.util.concurrent.ThreadPoolExecutor . I noticed that ThreadPoolTaskExecutor implements java.util.concurrent.Executor, but it does not implement the sub-interface java.util.concurrent.ExecutorService, which is declared by the wrapped instance java.util.concurrent.ThreadPoolExecutor. This prevented me from using the bean as an ExecutorService - I was limited to the Executor interface. As a result I eventually switched to a factory method on java.util.concurrent.Executors to declare my bean.
ExecutorService exposes a number of useful methods, particularly shutdown(). If ThreadPoolTaskExecutor implemented ExecutorService, it would need to delegate the additional (12) methods to the underlying ThreadPoolExecutor, but presumably no big deal with that.
Opinions? Is it worthwhile implementing ExecutorService in ThreadPoolTaskExecutor so that the full interface of ThreadPoolExecutor is exposed?