RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

[Remi Forax]

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 

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.

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)

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.

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

Rémi 

---
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" <jlaskey at openjdk.java.net>
> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "security-dev" <security-dev at 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