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.
Roger
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