RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

Mandy Chung mandy.chung at oracle.com
Tue Dec 8 20:19:02 UTC 2015


> On Dec 8, 2015, at 6:50 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> 
> On 8 Dec 2015, at 14:33, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> Adding an argument to the most flexible constructor of Thread bulks up
>> an already heavy weight constructor.  Look at the cases being replaced,
>> none of them use all of the arguments.  The stackSize, for example, is rarely
>> used and is nearly useless due to its implementation dependencies.
> 
> Right. The motivation for adding an additional constructor that accepts a
> superset of arguments is for maximum flexibility. Since this is targeted at
> the advanced user, then it should be ok, but I agree it looks a little unwieldy.
> 
>> Would you consider using a static Factory method (aptly named) instead
>> of a constructor?
> 
> Possibly, I went down the constructor route for consistency with what is
> already there. The usage pattern of extending Thread is also very common.


Since this is target for advanced users, what’s your thought of defining a new subclass extending Thread?

Mandy


More information about the core-libs-dev mailing list