On Wed, Dec 3, 2014 at 7:26 AM, Doug Lea <d...@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.
