JDK-8074460 : Always print seeds used in [Splittable]Random instances in java.math tests
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.math
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-03-05
  • Updated: 2024-03-05
  • Resolved: 2015-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u421Fixed 9 b55Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
This is what I found:

1. Seed is constant hence redundant to print on failure
./BigInteger/ModPow.java
./BigInteger/PrimitiveConversionTests.java

2. Seed is printed on failure
./BigDecimal/StringConstructor.java

3. Seed is not printed on failure
3.1 Uses parameterless Random()
./BigInteger/BigIntegerTest.java
./BigInteger/ModPow65537.java
./BigInteger/SymmetricRangeTests.java

Fixing these tests to print the seed is not a problem as a construct such as

    private static int seed = new Random().nextInt();
    private static Random rnd = new Random(seed);

which is used in the StringConstructor test could be applied. The Random instance actually used is ‘rnd’ and while its seed itself is random it is known and may be printed.

A slight change might actually be better:

    private static Random rnd;
    private static long seed;

    static {
        rnd = new Random();
        seed = rnd.nextLong();
        rnd.setSeed(seed);
    }

3.2 Uses parameterless SplittableRandom()
./BigInteger/PrimeTest.java

Something similar to what is currently done in StringConstructor could be done here as well to fix the problem. SplittableRandom does not have a setSeed() method so the other approach is infeasible.

Note that there is no way to retrieve from an instance of either class the seed that was used by the parameterless constructor.
Comments
URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/50ccf30fafcd User: lana Date: 2015-03-18 00:54:38 +0000
18-03-2015

URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50ccf30fafcd User: bpb Date: 2015-03-07 15:17:37 +0000
07-03-2015

Review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032092.html
06-03-2015

Another good suggestion!
05-03-2015

A good practice for a test using a random numbers without a fixed seed is to accept the seed from a command line option if it is given. jtreg ... -Dseed=0x123 if (seedDefinedInEnvironment() ) rnd = new Random(seedFromEnvironment); else { // Use a fresh seed }
05-03-2015

Good suggestion from Stuart Marks: "I'd suggest printing out the seed unconditionally, instead of just on failure. If the test crashes unexpectedly, or is timed out by the test framework, it might not go through the code path of print-on-failure, so might as well print it out at the beginning and be done with it."
05-03-2015