RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom

Doug Lea dl at cs.oswego.edu
Wed Dec 3 22:15:32 UTC 2014

On 12/03/2014 02:03 PM, Martin Buchholz wrote:
> On Wed, Dec 3, 2014 at 9:38 AM, Doug Lea <dl at cs.oswego.edu> wrote:
>> ... Of the two choices, housing the code in ThreadLocalRandom
>> seems logistically a bit easier. Then SplittableRandom could use
>>   private static final AtomicLong defaultGen =
>>     new AtomicLong(ThreadLocalRandom.current().nextLong());
> Oh, I think I see - you're saying we don't need a new public API,
> because ThreadLocalRandom.current() is already exactly the source of
> random seed what we want?

No public API because systemSeed need only be implemented
inside TLR, for its initial seed. Then the others can get their seeds
using ThreadLocalRandom.current().nextLong(), unless
java.util.secureRandomSeed is set (which I didn't illustrate above).
In other words, across all non-secure generators, you only need
one system-generated seed.


More information about the core-libs-dev mailing list