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

Chris Hegarty chris.hegarty at oracle.com
Tue Jan 15 10:12:12 UTC 2013

On 01/15/2013 09:57 AM, Aleksey Shipilev wrote:
> On 01/15/2013 01:40 PM, Peter Levart wrote:
>> If this is an API change, then it might as well be a change in the
>> serializability of the ThreadLocalRandom instance. Since TLR extends
>> Random which is already Serializable, this could be done by throwing
>> appropriate exception in writeObject().
>> I don't think anyone would really notice.
>> Serializability of a java.util.Random is meant to transfer the state of
>> the object over the wire (including current seed). This can't be done
>> for ThreadLocalRandom since it's a singleton with thread-bound state. So
>> serializability of TLR is dubious.
> That's an interesting thought indeed. However, I would say already
> receiving TLR from the stream and throwing the "don't want it" exception
> would be surprising. We are at the curse of having these fields exposed
> in serialized form; the only thing we can do is to minimize further leakage.
> Chris, do you need help preparing the patch?

I'm still not sure that we have agreement here.

My preference, for what it's worth, is to forge ahead with Peter's 
suggestion, and update the TLR specification to throw in the case of 
writeObject. I believe this would be the best solution.

Add similar text to the class description:

  * Note, that although ThreadLocalRandom inherits Serializable
  * interface from Random, it is not intended to be Serializable.
  * Appropriate serialization methods are implemented to throw
  * NotSerializableException.

   * Throws NotSerializableException, since TLR
   * objects are not intended to be serializable.
  private void writeObject(java.io.ObjectOutputStream out)
      throws NotSerializableException
      throw new NotSerializableException("Not serializable.");

  private void readObject(java.io.ObjectInputStream in)
      throws NotSerializableException
      // swallow all field data.

This of course, is subject to spec change approval.


> -Aleksey.

More information about the core-libs-dev mailing list