Naming of thread pools (Executors)

Aleksey Shipilev aleksey.shipilev at oracle.com
Mon May 18 07:32:12 UTC 2015


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?

Thanks,
-Aleksey





More information about the core-libs-dev mailing list