class SplittableRandom

[Doug Lea]

On 07/16/13 12:55, Mike Duigou wrote:

> I worry that it will be difficult/impractical for those who desire a
> different algorithm to replace SplittableRandom with their own (P)RNG whether
> it be for secure randomness or better statistical properties. Since
> SplittableRandom doesn't implement any interfaces it's hard to provide any
> form of substitute except by crufty override of every method.
>
> I know that this ground has already been travelled but it remains a concern
> for me.

Yes.

To recap the reasons we decided to not pursue this for JDK8:

1. Impact on java.util.Random.

No matter what, you'd need to somehow touch this class,
which (justifiably) invites detailed study of any
compatibility issues.

2. Questionability of default implementations.

Impleemntation details of some non-core methods (for
example, nextDouble, nextInt(bound)) are often sensitive to
quirks of base algorithms, so perhaps it would be best not to
supply any default implementations. On the other hand, not
doing so would not be in keeping with other new JDK8 interfaces.
It requires more thought about whether or how to resolve.

3. Finite parallel streams

Some of the coolest things you can do with SplittableRandom
stem from these new methods; that don't have obvious
analogs in most other generators. So even with an interface,
SplittableRandom would likely have some distinct methods.

None of these are show-stoppers, or probably all that hard
to address. But starting up an effort on it at this
point for JDK8 seemed like a bad idea. And as mentioned
in my initial post, the case for introducing
SplittableRandom without this seems pretty solid.


-Doug