JEP 356 will provide new interface types and implementations for pseudorandom number generators (PRNGs), including jumpable PRNGs and an additional class of splittable PRNG algorithms (LXM).

JEP 356 creates a new interface, RandomGenerator,providing a uniform API for all existing and new PRNGs. RandomGenerator provides a cluster of methods to provide randoms numbers of various type persuasions: ints, longs, doubles, nextBoolean, nextInt, nextLong, nextDouble, and nextFloat. The RandomGenerator interfaces will be specialised by a number of sub interfaces including:

• SplittableRandomGenerator providing methods named split and splits.
• JumpableRandomGenerator providing methods named jump and jumps.
• LeapableRandomGenerator providing methods named leap and leaps.
• Additionally, ArbitrarilyJumpableRandomGenerator will extend LeapableRandomGenerator and also provide additional variations of jump and jumps that allow an arbitrary jump distance to be specified. An AbstractFactory class, RandomGeneratorFactory, will be provide with the dual functionality to locate and construct instances of RandomGenerator implementations. The RandomGeneratorFactory will use the ServiceLoader.Provider API to register RandomGenerator implementations.

Test success criteria

• Test success criteria are exit criteria for testing
• Test success criteria help to see if the testing is successful
• Test success criteria are handled as sub-tasks of a test plan
• Test success criteria sub-tasks are closed when satisfied
• See sub-tasks of this plan template for test success criteria examples

Depending on the changes introduced by the JEP, it is expected by the test plan to specify relevant criteria. If the JEP is adding ...

• new code - block, method code coverage
• public API - public API coverage
• options - options coverage
• specification, javadoc - specification coverage
• etc.

Please see individual criteria descriptions for more information.

Test plan handling and lifecycle

• A test plan should be a "JEP Task", blocking the JEP
• A test plan should be moved to closed state before the JEP is integrated
• A test plan can only be closed once test methodology is explained and test success criteria are reached
• It is recommended that you create a new test plan for a JEP by cloning this template
• Portions of description in italic are comments and supposed to be removed
• Optional sections of the test plan can be removed
• Additional sections or sub-sections should be added as needed
• All non-applicable test success criteria sub-tasks should be dropped
• Additional criteria sub-tasks should be added as needed

See linked issues for examples of previously created test plans.

1 Test Methodology

• All existing tests for Random, ThreadLocalRandom, and SplittableRandom
  should continue to be used.

• New test, probably to be applied just once: The output of the refactored
  versions of Random, ThreadLocalRandom, and SplittableRandom (before
  repairing the two newly detected weaknesses) should be spot-checked against the existing (JDK 8) implementations to verify that their behavior remains
  unchanged.

• New test, probably to be applied just once: The output of the LXM algorithms
  should be spot-checked against the C-coded versions used for quality
  verification with TestU01 and PractRand.

• New test, to become a permanent part of the test suite: The jump() and
  leap() methods should be tested to verify that they do travel around the state cycle by the claimed distance. For example, starting from any specific initial state, the sequence of operations nextLong(); jump() ought to leave a
  generator in the same state as the sequence of operations jump(); nextLong().

2 Test Inventory (optional)

In some cases it helps to spell which tests are to be reused or added to test the feature. In some cases some tests are not longer relevant and should be removed/deprecated. This section can be used to list specific tests, test groups or test types such as unit, functional, integration, manual/automated, negative, etc.

This section should also be used to point to which test groups, tiers, etc, the new tests will be added.

Existing Tests

New Tests

Deprecated Tests

3 Test Configurations (optional)

It is often important to make sure that correct sets of tests be executed in the correct set of configurations, which could be set of platforms or VM flag combinations. Notice that simply repeating JDK supported platforms is redundant, so this section could be used when there are some specific requirements.

4 Success Metrics

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

• Pierre L'Ecuyer and Richard Simard. TestU01: A C Library for Empirical Testing of Random Number Generators. ACM Transactions on Mathematical Software 33, 4 (August 2007), article 22. ISSN 0098-3500. http://doi.acm.org/10.1145/1268776.1268777

• Richard Simard. TestU01 version 1.2.3 (August 2009). http://www.iro.umontreal.ca/~simardr/testu01/tu01.html

• Pierre L'Ecuyer and Richard Simard. TestU01: A Software Library in ANSI C for Empirical Testing of Random Number Generators: User's guide, compact version. Département d'Informatique et de Recherche Opérationnelle, Univerité de Montréal, May 2013. http://www.iro.umontreal.ca/~simardr/testu01/guideshorttestu01.pdf

• Chris Doty-Humphrey. PractRand version 0.90. July 2014. http://pracrand.sourceforge.net [That's not a typo. The name of the software is "PractRand"
  but the SourceForge project name is "pracrand".]

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