RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

[Peter Levart]

On 01/15/2013 09:55 AM, Alan Bateman wrote:
> On 14/01/2013 23:55, Doug Lea wrote:
>>
>> Thanks to Alan and Aleksey for noticing this and to Chris for
>> offering some serialPersistentFields incantations!
>>
>> (The only way to serialize a TLR represents a strange abuse to
>> begin with. You'd need to save the result of
>> ThreadLocalRandom.current() in a field of a serialized object.
>> Which would be a terrible idea ...)
> It does seem nonsensical. Given that the padding isn't used then the 
> simplest thing might be to do "nothing", meaning treat this update as 
> an API change that changes the serialized form. I don't see any 
> compatibility issues as deserialization on an older release will just 
> leave the padding fields with their default values (and as they are 
> unused then it shouldn't matter). I think this would be simplest than 
> adding serialPersistentFields and a writeObject to write these unused 
> fields.
>
> -Alan
If this is an API change, then it might as well be a change in the 
serializability of the ThreadLocalRandom instance. Since TLR extends 
Random which is already Serializable, this could be done by throwing 
appropriate exception in writeObject().

I don't think anyone would really notice.

Serializability of a java.util.Random is meant to transfer the state of 
the object over the wire (including current seed). This can't be done 
for ThreadLocalRandom since it's a singleton with thread-bound state. So 
serializability of TLR is dubious.


Regards, Peter