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

Chris Hegarty chris.hegarty at oracle.com
Tue Jan 15 13:49:48 UTC 2013

On 01/15/2013 01:37 PM, Alan Bateman wrote:
> On 15/01/2013 13:25, Doug Lea wrote:
>> :
>> And so, anything sensible that we do here will have the
>> (too nice?) effect of "fixing" the errors of anyone
>> crazy enough to do this -- rather than deserializing into
>> a non-thread-local ThreadLocalRandom, it will attach to
>> the common one.
>> Given all this, I think Heinz's suggestion below looks suitable.
>> Chris, do you agree about the serialization incantations?
> Heinz's proposal is fine but I think you also have the option of just
> dropping the pad fields from the serialization form (meaning no need for
> serialPersistentFields or writeObject). Technically it would be "API
> change" but one that shouldn't have any impact as the fields were never
> used and hence deserializing to their default value is okay.

But wouldn't there be an issue with JDK7 TLR streams being deserialized 
by JDK8, pad fields would be left in the Object input steam? If so, then 
we're down the road of having to have a readObject, etc... and possibly 
back to serialPersistentFields?


> -Alan

More information about the core-libs-dev mailing list