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](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](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](http://www.iro.umontreal.ca/~simardr/testu01/guideshorttestu01.pdf)

  - Chris Doty-Humphrey. PractRand version 0.90. July 2014.
    [http://pracrand.sourceforge.net](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.