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