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

[Martin Buchholz]

On Wed, Dec 3, 2014 at 7:26 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 12/02/2014 05:34 PM, Martin Buchholz wrote:
>>
>> I support Peter's initiative and am willing to help review if we have
>> general consensus about the direction.
>>
>
> Peter's implementation scheme of using Unix /dev/urandom
> or the Windows Crypto API (or something else on failure) seems
> like the best options. I don't see why we shouldn't place this
> as a jdk9 public static method in one of the existing random classes
> though (Random, SplittableRandom, ThreadLocalRandom, SecureRandom),
> rather than as separate entity. (If desired, for jdk8 backport,
> it could be non-public, with cheats to access.)

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.

There is a generalized fear with initialization-time utilities that we
want as few dependencies as possible, to avoid a clinit method that we
are not yet ready to execute, or may never need to execute.  That is
my fear with SecureRandom, which does provider-y stuff I don't
understand.  We don't actually need java crypto yet.