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.

And one more thing. With moving of fields off the TLR object, the 
semantics of de-serialization change. JDK7 TLR deserializes into an 
instance which is not thread-bound with the copy of the seed of original 
instance. So serializing/deserializing acts as a form of cloning the 
instance and detaching the copy from the thread. Proposed TLR can't keep 
this semantics (unless it is modeled as a private subclass of TLR for 
example which overrides existing logic and provides a writeReplace() 
method that replaces it with plain TLR instance before serializing).

Regards, Peter