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.
-Chris.
-Aleksey.
