RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread
peter.levart at gmail.com
Wed Jan 16 07:27:13 UTC 2013
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
On 01/15/2013 05:33 PM, Chris Hegarty wrote:
> Updated 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.
> 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.
More information about the core-libs-dev