----- Mail original ----- > De: "Jim Laskey" <james.las...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Jim Laskey" <jlas...@openjdk.java.net>, "core-libs-dev" > <core-libs-dev@openjdk.java.net>, "security-dev" > <security-...@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 <fo...@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