On Aug 27, 2013, at 11:47 PM, Mike Duigou <mike.dui...@oracle.com> wrote: > ThreadLocalRandom:: > > - I don't understand the point of having a writeObject() if the readResolve() > ignores the result. My expectation for a serialized TLR might be that upon > de-serialization the seeding state is restored. If that isn't provided, why > offer any serialization at all? Alternately we should be more explicit that > the seeding state is not part of the serialization. >
My understanding is it preserves compatibility when deserializing, as indicated by the internal comment: * still allowing a call from constructor. Note that * serialization is completely unnecessary because there is only a * static singleton. But we generate a serial form containing * "rnd" and "initialized" fields to ensure compatibility across * versions. > - There's no test for the serialization behaviour. > Right, neither for the TCK AFAICT. (There is a serialization test for Random in the JCK.) Issue logged, 8023896. > SplittableRandomTest:: > > - executeAndCatch -> assertThrows perhaps? There are a few implementations of > assertThrows around in other tests (which haven't been collected into a > library yet). > There are also a few implementations of executeAndCatch lying around too caused by me :-) I agree it is a bad name. We should change all of 'em. I logged another issue, 8023897. I wish there was a common library of additional functionality that is missing from TestNG itself. Paul.