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

Aleksey Shipilev aleksey.shipilev at oracle.com
Tue Jan 15 10:20:35 UTC 2013

On 01/15/2013 02:12 PM, Chris Hegarty wrote:
> On 01/15/2013 09:57 AM, Aleksey Shipilev wrote:
>> Chris, do you need help preparing the patch?
> I'm still not sure that we have agreement here.

Sorry, I should not have replied in this thread.

> 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.
>  }

I'm technically OK with this, plus:
  + readResolve returning the actual TLR
  + SVUID fixup

> This of course, is subject to spec change approval.

...but this leads me back to thinking if we should still persist the
leaked serialization form (serialPersistentFields code put together by
Heinz is fine) to make this functionality in JDK8 for Doug to rely on,
and then back off to suggestions for collapsing serialization forms.


More information about the core-libs-dev mailing list