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

[Chris Hegarty]

> On 8 Dec 2015, at 8:19 p.m., Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
>> 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?

I don't have a strong objection against a new subclass, but I seems like overkill for something so simple, given there is already low-level / advanced details exposed in the current API, like stack size. Unless you are thinking of creating a new home for other Thread and thread-local related operations, that could be added subsequently?

-Chris.