> On May 17, 2015, at 9:32 PM, Aleksey Shipilev <aleksey.shipi...@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
