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
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
should continue to be used.
New test, probably to be applied just once: The output of the refactored
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
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
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.
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.
|100% public API coverage
|80% block coverage for Java code
|100% specification change coverage
|Verify regression test stability
|100% option combination coverage
|80% line coverage for native code
|100% non-trivial method coverage