RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

Jim Laskey james.laskey at oracle.com
Mon Nov 23 13:58:50 UTC 2020


Rémi,

> 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.

> 
> 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" <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



More information about the security-dev mailing list