RFR (S) 8059677: Thread.getName() instantiates Strings

roger riggs roger.riggs at oracle.com
Mon Nov 10 14:31:01 UTC 2014

Hi Aleksey,

1) The Thread class javadoc says:
" Unless otherwise noted, passing a {@code null} argument to a constructor
  * or method in this class will cause a {@link NullPointerException} to be
  * thrown."

So, NPE is already specified for setThreadName(null) or any other method.
I'm not infavor of adding the Objects.requireNonNull, the NPE will be 
thrown soon enough
and it is just noise in the source code in most cases that creates 
larger bytecodes
and extra work for the compiler /interpreter.

2) About not storing the name as a String, I have some vague 
recollection of the
issue being related to exposing an object settable by the application 
that can be used
with synchronize and allows communication and sync issues between threads.

Just because some test doesn't fail, doesn't mean there isn't a 
design/implementation constraint.


On 11/10/2014 9:08 AM, Aleksey Shipilev wrote:
> Hi Chris,
> Thanks for taking a look!
> On 11/10/2014 02:52 PM, Chris Hegarty wrote:
>> Trivially, after your changes will NPE be thrown if setName(null), as it
>> is today ?
> There is no way it could throw NPE now, therefore the behavior is
> different. The spec says nothing about NPE though, but it feels wrong to
> pass the null String to setNativeName. I should add
> Objects.requireNonNull there. Will wait for more feedbacks, and update
> the webrev.
> -Aleksey.

More information about the core-libs-dev mailing list