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

[Doug Lea]

On 12/04/2014 07:22 PM, Doug Lea wrote:

> Because Random, SplittableRandom, and ThreadLocalRandom all use the
> same basic approach, they can/should use the same mechanism.

In other words, to establish a common default-constructor-seed
generator internal to the JDK. So we only need one environmental
seed to start it off, and can remove some redundancies.

> Placing the mechanics in TLR seems to work out best.

Well, except that on Windows, we'd still need to create
a .dll just for the sake of calling CryptGenRandom (or
RtlGenRandom?), which seems like a bad move all around.
If we are trying to reduce initialization costs,
it would be better and faster if this were integrated
with other platform-specific JVM startup. (Requiring a
separate .dll also makes it impossible for us to create
standalone j.u.c builds for previews etc.) Which brings
us back to establishing some means of getting from the JVM,
only once, 8 bytes of environmentally-derived bits for a
within-JDK caller. Doing this might be a good opportunity
for exploiting any upcoming modularity support. Or short of
that, placing it in an existing JVM interface class like Unsafe.
Any thoughts?

> (Also, at some point we might reconsider our cowardice about not
> improving the internal java.util.Random algorithm. j.u.Random is
> much more commonly used, and does not fare well on quality tests.
> On the other hand, the more that users instead choose to use
> SR or TLR, the better.)
>

The main problem is code (not just JDK test code) that hardwires
expected Random.next* output under given seeds. Which might be
enough reason to leave it alone.
Do any CCC members have an opinion?

As a lesser but still worthwhile target though, I can't think of
a reason not to change java.lang.Math.random() to use TLR
to get faster and better-quality values. (Because there is no
way to explicitly seed Math.random, there is no hardwiring problem.)
Some existing javadoc for it saying that it creates a new
java.util.Random() should be deleted, although I don't
think it has any user-visible impact.
http://docs.oracle.com/javase/8/docs/api/java/lang/Math.html#random--

-Doug