ThreadLocalRandom clinit troubles

[Martin Buchholz]

ThreadLocalRandom's clinit method creates an intermediate broken state of
ThreadLocalRandom and then proceeds to run some networking code to get some
more machine-specific entropy in initialSeed().  This will fail if the
networking code ever recursively uses a (not yet functional)
ThreadLocalRandom.  The clinit for InetAddress can cause arbitrary code to
be run,

at
java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:354)
at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393)
at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
at java.net.InetAddress$3.run(InetAddress.java:923)
at java.net.InetAddress$3.run(InetAddress.java:918)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.InetAddress.createNSProvider(InetAddress.java:917)
at java.net.InetAddress.<clinit>(InetAddress.java:962)

if the sun.net.spi.nameservice.provider system property is defined.

The current strategy of ThreadLocalRandom relying on other java code for
initialization seems risky.  Safer would be to have native code provide
some entropy at program startup for use by ThreadLocalRandom.  I don't have
a clean solution for this problem (other than to rip out initialSeed()).
 Strictly more reliable would be to mix in the entropy from the system at
the end of ThreadLocalRandom's clinit instead of the beginning, but the
basic problem remains.