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

ecki at zusammenkunft.net ecki at zusammenkunft.net
Tue Dec 8 23:07:37 UTC 2015


Hm,

In need of an API I would stick to an executor. Maybe (but thats likely not needed) have a common (caching) thread pool for such tasks. I would  kt encourage using those stray thread classes.

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-----Original Message-----
From: Mandy Chung <mandy.chung at oracle.com>
To: Roger Riggs <roger.riggs at oracle.com>
Cc: core-libs-dev at openjdk.java.net
Sent: Mi., 09 Dez. 2015 0:02
Subject: Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

Yes but it won’t work for existing classes that extend Thread.

Mandy

> On Dec 8, 2015, at 1:08 PM, Roger Riggs <roger.riggs at oracle.com> wrote:
> 
> Hi,
> 
> Using a static factory method, in Thread, would I think be preferable to creating a whole new class
> and provide the opportunity to name it intuitively.
> 
> $.02, Roger
> 
> 
> On 12/08/2015 03:53 PM, Mandy Chung wrote:
>>> On Dec 8, 2015, at 12:28 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>> 
>>>> 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?
>> I am not thinking of any new thread-local related operation.  The boolean inheritThreadLocals argument is added to one single constructor that forces the caller to pass the null/zero or other default value is not ideal.
>> 
>> Since the audience of this API would be small, defining a new class with the appropriate constructors (perhaps no stackSize) is a good alternative.  The change would still be simple.
>> 
>> Mandy
> 




More information about the core-libs-dev mailing list