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.ch...@oracle.com> To: Roger Riggs <roger.ri...@oracle.com> Cc: core-libs-dev@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.ri...@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.hega...@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 >
