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

[Martin Buchholz]

On Wed, Dec 3, 2014 at 9:38 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 12/03/2014 12:20 PM, Martin Buchholz wrote:
>
>> I don't think such a general purpose utility belongs in
>> SplittableRandom or ThreadLocalRandom - those are the clients.  Random
>> is a slightly better fit, but still not great.
>
>
>
> Perhaps one of these could be made to be a good fit.
> As of now, this new method (systemSeed) would be called at most
> twice ever -- during static init of SplittableRandom and
> ThreadLocalRandom. Either of these could be reworked to
> use a high-quality derived seed from the other as its
> initial seed. In which case systemSeed would be called only once.
> 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());
>
> (For that matter, java.util.Random could use the same
> idea for its initial seed.)

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?  That seems pretty good ... except that the
quality of TLR's PRNG is (expected to be) much lower than what we get
from the system - /dev/urandom should be at least a CSPRNG, but TLR is
not.  So ThreadLocalRandom.current().nextLong() is more predictable
than some users might like?  I'm still thinking a public API that
promises cryptographically secure bits without blocking seems
worthwhile.