Take 2 <was> Re: RFR 8023155: Ensure functional consistency across Random, ThreadLocalRandom, SplittableRandom

[Paul Sandoz]

On Aug 27, 2013, at 11:47 PM, Mike Duigou <mike.duigou at 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.