No, the original function names are better than your replacements, because they accurately describe what the functions will actually do instead of assuming they

No, the original function names are better than your replacements, because they accurately describe what the functions will actually do instead of assuming they know what the user wants. Your names imply non-trivial differences in the way the functions work. These are library functions, so their names must be carefully chosen to imply only what the contract of the actual method supports. In particular: Executors.instantiateThreadManager() You lose information about the thread count (single thread). Also, a nitpick I know, but in Java new means instantiate, so just say new and save typing. Also, an executor is not guaranteed to be a thread manager in any meaningful sense. It is only guaranteed to be an Executor. exec.queueForAsyncExecution() This may not actually be async. 9/10 it is, but the interface does not guarantee async, just a de-coupling from queuing and execution. exec.executeQueued() This misses the fact that calling shutdown will deny future tasks from being queued after it is called. This is actually a great example of why function names are not a sufficient replacement for appropriate comments.