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

Peter Levart peter.levart at gmail.com
Tue Jan 15 10:03:59 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.

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

More information about the core-libs-dev mailing list