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.