Naming of thread pools (Executors)

[Steven Schlansker]

> On May 17, 2015, at 9:32 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> 
> On 05/17/2015 10:55 AM, Peter Hansson wrote:
>> Hi, 
>> 
>> I would like create a patch for https://bugs.openjdk.java.net/browse/JDK-8016248.
>> MOTIVATION: Today thread pools created by the Executors method are always prefixed with "pool". The developer can work around this by providing his own ThreadFactory but if he wants to have the default JDK behaviour then it means he has to replicate code in the JDK. The string "pool" is hardcoded in the JDK. The fact that threads cannot be identified by their purpose is annoying especially when working with JEE servers.
>> 
>> SUGGESTION:
>> The idea is to amend private classes Executors.DefaultThreadFactory and Executors.PrivilegedThreadFactory to optionally accept a name prefix in their constructor.Then methods Executors.defaultThreadFactory() and Executors.privilegedThreadFactory() will be overloaded to optionally accept a name prefix.
>> With this change the developer can now use a custom thread name prefix. If he wanted to do:
>> 
>>   Executors.newFixedThreadPool(3);  // standard, results in "pool" prefix
>> 
>> He could instead use a developer supplied ThreadFactory yet still using JDK's ThreadFactory:
>>   Executors.newFixedThreadPool(3, Executors.defaultThreadFactory("snmpworker"));
>> 
>> Good idea ?  Bad idea?  Any negative side effects ?
> 
> I think that's a sane improvement.
> 
> But the next thing you'd want are shortcuts for thread daemon status,
> priority, and maybe even the context classloader. Having that in mind,
> it might be worthwhile to explore making
> Executors.simpleThreadFactory(String prefix, boolean isDaemon, int
> priority) and/or overloads and/or some builder variant of it?

I'm sure everyone has seen this, but in case not, I use this all the time:
http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/util/concurrent/ThreadFactoryBuilder.html