ThreadLocalRandom clinit troubles

Peter Levart peter.levart at
Thu Jun 19 07:49:43 UTC 2014

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
 > at java.util.ServiceLoader$LazyIterator.hasNext(
 > at java.util.ServiceLoader$1.hasNext(
 > at$
 > at$
 > at Method)
 > at
 > at<clinit>(
 > if the 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 
 > 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:

Regards, Peter

More information about the core-libs-dev mailing list