RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread
Peter Levart
peter.levart at gmail.com
Tue Jan 15 09:40:31 UTC 2013
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
More information about the core-libs-dev
mailing list