On Aug 27, 2013, at 11:47 PM, Mike Duigou <[email protected]> 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.
