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

Chris Hegarty chris.hegarty at oracle.com
Wed Feb 20 14:13:34 UTC 2013


On 20/02/2013 12:16, Martin Buchholz wrote:

On Wed, Feb 20, 2013 at 3:16 AM, Chris Hegarty <chris.hegarty at oracle.com_ _<mailto:chris.hegarty at oracle.com>> wrote: Martin, Alan, OK, I finally got back to this. I agree that Martins changes should be fine for jdk8, but removing all these fields may cause an issue with jdk7. Removing pads, fine. The rnd and initialized fields are still applicable in jdk7 ( or 7 will need changes to remove their dependency ). For example, a serialized TLR from jdk8 with Martins changes, deserialized with jdk7 would contain no field values, therefore the defaults would apply. Calling setSeed on this object would not throw the expected UOE. My expectation was that with my changes, the default serialization would apply, and the serialized form would contain initiatialized=1. rnd would not be in the serialized form, but would deserialize to 0, which is the same as currently done.

Yes, you are right. For some reason I was thinking that 'initialized' field was also removed from this version. So this is fine.

Completely untested.

BTW, we still don't have a good story on cross-JDK serialization testing.

I think minimally TLR in jdk8 needs to keep initialized, and possibly write some reasonable value for rnd. Whether rnd needs a reasonable value is a reasonable question.

Unfortunately, if we agree that rnd needs a reasonable value then we are stuck with serialPersistentFields, etc ( less the padding ).

How about (and additionally remove the pads):

--- a/src/share/classes/java/util/concurrent/ThreadLocalRandom.java Tue Feb 19 20:52:39 2013 -0800 +++ b/src/share/classes/java/util/concurrent/ThreadLocalRandom.java Wed Feb 20 14:08:28 2013 +0000 @@ -398,7 +398,7 @@ public class ThreadLocalRandom extends R throws java.io.IOException {

      java.io.ObjectOutputStream.PutField fields = out.putFields();

-Chris.



More information about the core-libs-dev mailing list