RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Jim Laskey" <james.laskey at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Jim Laskey" <jlaskey at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>, "security-dev"
> <security-dev at openjdk.java.net>
> Envoyé: Lundi 23 Novembre 2020 14:58:50
> Objet: Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

> Rémi,

Hi Jim,

> 
>> On Nov 21, 2020, at 8:03 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> Ok, i've taking the time to read some literature about random generators because
>> for me the Mersenne Twister was still the king.
>> 
>> The current API proposed as clearly two levels, you have the user level and the
>> implementation level, at least the implementation level should seen as a SPI
> 
> Yes, We agree. It was decided that we work on the SPI separately from the
> original JEP. IMHO the implementation issues are too complex for a single JEP.
> So, the goal is to release the user level now, and refine the SPI at a later
> date. Only RandomGenerator (with descendant interfaces) and
> RandomGeneratorFactory will be public facing in the first release.
> 
> 
>> 
>> RandomGenerator is the user facing API, for me it should be the sole interface
>> exposed by the API, the others (leap, arbitrary leap and split) should be
>> optional methods.
> 
> Fair enough, but if your task requires leapable, you might be disappointed when
> you get an UnsupportedOperationException invoking leap. I personally like the
> "to the quick" ability of using LeapableGenerator for narrowing down the
> search.
> 
>    LeapableGenerator leapable = LeapableGenerator.all().findFirst().orElseThrow();
> 
> Open for discussion.

For me, it's not different from
   RandomGenerator leapable = RandomGenerator.getLeapableGenerator();

The question is: does this generator will be used directly or will it be sent through several layers of API,
because if it travels a lot, then a specific interface is better, otherwise a generic interface is better because it's easier to use from a user perspective and easier to maintain because you encode less knowledge.

> 
>> 
>> In term of factory methods, we should have user driven methods:
>> - getDefaultGenerator() that currently returns a L64X128MixRandom and can be
>> changed in the future
>> - getFastGenerator() that currently returns a Xoroshiro128PlusPlus and can be
>> changed in the future
>> - getDefault[Splitable|Leapable|etc]Generator that returns a default generator
>> with the methods splits|leaps|etc defined
>> - of / getByName that returns a specific generator by its name (but mov ed in a
>> SPI class)
> 
> I'm concerned that the "can be changed in the future" aspect of your default
> methods will create a false reliance. We sort of have default now with the
> java.util.Random class. If we were to change the underpinnings of Random all
> heck would break loose. We already ran into that aspect during testing - tests
> that relied on sequences from fixed seeds.

The incantation all().findFirst() has the exact same issue.

I believe that the fact that there are several defaults shield you a little because it's understood that those default will change from time to time.

> 
> We try to discourage the use of 'of', but there is a class of user (machine
> learning for example) that wants to be able to specify exactly. Often, choosing
> a specific fast prng for testing and then a more sophisticated one for
> production. The main purpose for RandomGenerator is swapability.


If of() is part of the SPI, i think it's fine, because you are explicitly asking for an implementation.
There is still the question about what implementations is provided for a specific jdk.

> 
> 
>> 
>> The example in the documentation should use getDefaultGenerator() and not of()
>> to avoid the problem all the programming languages currently have by having
>> over-specified that the default generator is a Mersenne Twister.
> 
> I have a problem with this as well. It would make it difficult to deprecate
> java.util.Random.

As i said above, not really because you are not asking for a specific implementation here but for a good default.
In practice, it will depends if the implementation is changed enough in the next releases of the JDK or not. 

> 
>> 
>> All methods that returns a stream of the available implementations should be
>> moved in the SPI package.
> 
> Open for discussion.

Rémi