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

[Peter Levart]

Just a minor note: In writeObject(), the code writes constant 0L for 
field "rnd". If we're trying to emulate the stream of JDK7 TLR then 
writeObject() could do better by writing the value of 
Thread.currentThread().threadLocalRandomSeed field...

Regards, Peter

On 01/15/2013 05:33 PM, Chris Hegarty wrote:
> Updated webrev:
>   http://cr.openjdk.java.net/~chegar/8005926/webrev.01/webrev/
>
>  * based on Aleksey initial webrev
>  * applied serialPersistentFields, writeObject, readResolve
>    ( as suggested by Heinz )
>  * did not apply readObject. It is unnecessary, defaultReadObject
>    will read all the fields off the stream
>
> readResolve is necessary to give us "good" behavior ( as noted 
> previously ).
>
> Once integrated, I will file a new bug to track the possible change of 
> serialized form of TLR, and this can then remove 
> serialPersistentFields and writeObject, if successful.
>
> -Chris.
>
>
> On 01/15/2013 01:57 PM, Alan Bateman wrote:
>> On 15/01/2013 13:49, Chris Hegarty wrote:
>>>
>>> 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?
>> Technically deleting fields is an incompatible change as the stream will
>> not contain the fields. If someone is crazy enough to serialize with
>> jdk8 TLR and send it to a jdk7 release then the fields will have their
>> default value (as the values aren't in the stream). As the fields aren't
>> used then I don't think this should make a difference. Going the other
>> way shouldn't be an issue either as the pad fields will be ignored.
>>
>> -Alan.