RFR 8023155: Ensure functional consistency across Random, ThreadLocalRandom, SplittableRandom

[Paul Sandoz]

Hi,

This patch updates Random and ThreadLocalRandom to have functional consistency (for the most part) across Random, ThreadLocalRandom and SplittableRandom:

  http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/webrev/

  http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/specdiff/overview-summary.html


The PRNG of ThreadLocalRandom has been updated by Doug:

     * Even though this class subclasses java.util.Random, it uses the
     * same basic algorithm as java.util.SplittableRandom.  (See its
     * internal documentation for explanations, which are not repeated
     * here.)  Because ThreadLocalRandoms are not splittable
     * though, we use only a single 64bit gamma.


The stream-returning method gaussians() is removed from Random and TLR. Doug's explanation as to why SplittableRandom does not have nextGaussian is applicable to why it's not worth having sized and effectively infinite stream-returning gaussians() methods:

"There are many algorithms to choose from, that are all
independent of the underlying uniform RNG algorithm.
Plus, there are many more probability distributions
out there. Singling out a particular algorithm/method
for Gaussian stands mostly as an accident of history
in java.util.Random."


The nextFloat functionality has been left unmodified. Such un/bounded nextFloat methods do not exist on SplittableRandom, i don't think they carry their weight given the nextDouble functionality.


I have yet to define a common interface e.g. RandomGenerator that Random, ThreadLocalRandom and SplittableRandom could implement, but it would be very easy to do so. Any thoughts on doing this?

--

A JPRT run reported no corresponding failures.

Paul.