Rémi,
> 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.
>
> 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.
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.
>
> 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.
>
> All methods that returns a stream of the available implementations should be
> moved in the SPI package.
Open for discussion.
>
> Rémi
>
Cheers,
-- Jim
> ---
> An honest question,
> why do we need so many interfaces for the different categories of
> RandomGenerator ?
>
> My fear is that we are encoding the state of our knowledge of the different
> kinds of random generators now so it will not be pretty in the future when
> new categories of random generator are discovered/invented.
> If we can take example of the past to predict the future, 20 years ago, what
> should have been the hierarchy at that time.
> Is it not reasonable to think that we will need new kinds of random generator
> in the future ?
>
> I wonder if it's not better to have one interface and several optional
> methods like we have with the collections, it means that we are loosing the
> possibilities to precisely type a method that only works with a precise type
> of generator but it will be more future proof.
>
> Rémi
>
> ----- Mail original -----
>> De: "Jim Laskey" <jlas...@openjdk.java.net>
>> À: "core-libs-dev" <core-libs-dev@openjdk.java.net>, "security-dev"
>> <security-...@openjdk.java.net>
>> Envoyé: Mercredi 18 Novembre 2020 14:52:56
>> Objet: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
>
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is
>> found in RandomGenerator and RandomGeneratorFactory. Further description can
>> be
>> found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can be found at
>> http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
>>
>> old PR: https://github.com/openjdk/jdk/pull/1273
>>
>> -------------
>>
>> Commit messages:
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> - 8248862; Implement Enhanced Pseudo-Random Number Generators
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> - ... and 15 more:
>> https://git.openjdk.java.net/jdk/compare/f7517386...2b3e4ed7
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/1292/files
>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=00
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8248862
>> Stats: 13319 lines in 25 files changed: 11110 ins; 2132 del; 77 mod
>> Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
>> Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292
>>
>> PR: https://git.openjdk.java.net/jdk/pull/1292
