Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8255355

Test Plan for JEP 356: Enhanced Pseudo-Random Number Generators



    • JEP Task
    • Resolution: Fixed
    • P3
    • 17
    • core-libs
    • None


      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

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

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


        Issue Links

          There are no Sub-Tasks for this issue.



              mchhipa Mahendra Chhipa
              msheppar Mark Sheppard
              0 Vote for this issue
              3 Start watching this issue