JEP draft: Enhanced pseudo-random number generators

AuthorGuy Steele
OwnerGuy Steele
TypeFeature
ScopeSE
StatusDraft
Componentcore-libs / java.util
Discussioncore dash libs dash dev at openjdk dot java dot net
EffortS
DurationS
Reviewed byBrian Goetz
Endorsed byBrian Goetz
Created2017/12/07 19:09
Updated2019/04/08 20:23
Issue8193209

Summary

Provide new interface types and implementations for pseudorandom number generators (PRNGs), including jumpable PRNGs and an additional class of splittable PRNG algorithms (LXM). Refactor classes Random, ThreadLocalRandom, and SplittableRandom appropriately.

Goals

Non-Goals

It is not a goal to provide implementations of numerous other PRNG algorithms, only to provide a framework that can accommodate numerous other PRNG algorithms if others wish to code them. (However, we do suggest providing four common algorithms that have already been widely deployed in other programming language environments.)

Success Metrics

The output of the new LXM algorithms should pass the existing well-known TestU01 and PractRand test suites.

Jumpable and leapable PRNG algorithms should pass tests (TBD) that verify the commutativity of certain operations.

Motivation

We see five opportunities for improvement in the area of pseudorandom number generators in Java:

Description

We propose to create five new interfaces: Rng, SplittableRng, JumpableRng, LeapableRng, and ArbitrarilyJumpableRng. Roughly speaking:

We propose to refactor Random, ThreadLocalRandom, and SplittableRandom so as to share most of their implementation code and furthermore make that code reusable by other algorithms as well. This refactoring would create new public abstract classes AbstractRng, AbstractSplittableRng, AbstractJumpableRng, AbstractLeapableRng, and AbstractArbitrarilyJumpableRng, each of which requires an extending class to provide only implementations for methods nextInt(), nextLong(), and (if relevant) either split(), or jump(), or jump() and leap(), or jump(distance). After this refactoring, Random, ThreadLocalRandom, and SplittableRandom would all implement the Rng interface. Note that because SecureRandom is a subclass of Random, all instances of SecureRandom would also automatically support the Rng interface, with no need to recode the SecureRandom class or any of its associated implementation engines.

We propose to add new classes that extend AbstractSplittableRng (and therefore implement SplittableRng and Rng) to support six specific members of the LXM family of PRNG algorithms (the current prototype versions require less than 50 lines of code each):

We also propose to provide implementations of these widely-used PRNG algorithms:

This suite of ten algorithms would provide Java programmers with a reasonable range of tradeoffs among space, time, quality, and compatibility with other languages.

Alternatives

We considered simply introducing new interfaces while leaving the implementations of Random, ThreadLocalRandom, and SplittableRandom as is. This would help to make PRNG objects more easily interchangeable but would not make it any easier to implement them.

We considered refactoring Random, ThreadLocalRandom, and SplittableRandom without changing their functionality or adding any new interfaces. We believe this would reduce their overall memory footprint, but do nothing to make future PRNG algorithms easier to implement or use.

Testing

Risks and Assumptions

We believe this is a fairly small project and the risks are minimal. Probably the biggest burden is crafting the specification; second-biggest is testing. The refactoring of existing algorithm and the coding of new algorithms has already been completed.

Dependencies

None known.

Impact