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

[roger riggs]

Hi,

On 11/10/2014 9:54 AM, Aleksey Shipilev wrote:
> Hi Roger,
>
> On 11/10/2014 05:31 PM, roger riggs wrote:
>> 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.
> Ah, thanks! It is odd to see this specified in a blanked fashion in the
> class Javadoc, oh well. So we need to restore the NP check.
Class or package level specification of the default NPE behavior is now
preferred to avoid the extra bulk and repetitiveness of extra @throws...
>
>
>> 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.
> Sorry, I have a hard time understanding what you are saying. How would
> you guarantee NPE (as per Javadoc contract above) in the new version of
> Thread.setName otherwise?
My mistake,  an explicit check for null is needed in setName().
>> 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.
> Again, I don't quite understand. Is it about storing the reference to
> String as the thread name, that can potentially be used for external
> synchronization?
>
> If so, I have a hard time devising a sane test case that might fail with
> this change. Internal code does not synchronize on Thread.name. Anyone
> synchronizing on Thread.getName() result has broken synchronization with
> current code. Anyone synchronizing on Thread.getName() result after this
> patch will have that (ahem) fixed, plus a performance problem.
>
>
Potentially, any change we make to the implementation can result in a
change in application behavior, even changing from returning a unique String
to an immutable but constant String. For 9, this will have time to uncover
obscure application dependencies.  I'd be more cautious about 
backporting to 8.

Roger