ThreadLocalRandom clinit troubles

[Peter Levart]

Hi Martin,

What version of TLR are you looking at? As far as I remmember, the 
InetAddress-related code to obtain initial seed has been replaced by 
NetworkInterface.getHardwareAddress(). Is this still triggering the 
initialization of InetAddress or is this the case of using 
"java.util.secureRandomSeed" set to "true" ? Can you show the whole 
stack trace?

On 06/19/2014 06:25 AM, Martin Buchholz wrote:
 > 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.

Would it be acceptable for TLR to be functional even when invoked during 
it's clinit, but using a less randomized "seeder" (based only on current 
time) and after the "networking" or SecureRandom code is finished, 
complete the initialization of "seeder" state and clear the thread-local 
probe so that TLR's thread state is re-initialized afterwards. for example:

http://cr.openjdk.java.net/~plevart/jdk9-dev/TLR.seeder/webrev.01/

Regards, Peter