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

Reply via email to