RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom
martinrb at google.com
Wed Dec 3 17:20:34 UTC 2014
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.
More information about the core-libs-dev