ThreadLocalRandom clinit troubles

Martin Buchholz martinrb at
Thu Jun 19 18:04:19 UTC 2014

On Thu, Jun 19, 2014 at 1:22 AM, Alan Bateman <Alan.Bateman at>

> On 19/06/2014 05:25, 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(
>> 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.
> Using a name service provider other than the default is going to interact
> badly here. So is this configured to use the JNDI-DNS provider ("dns,sun")
> or something else? This provider mechanism has been a source of many
> problems, recursive initialization and stack overflow mostly because any
> custom provider is likely going to use the network and resolve host names.
> It can interact very badly with security when the provider doesn't have
> AllPermision because attempts to establish connections involve security
> checks that often need to do lookups too.
> So I'm curious if there is more to this stack trace to put more context on
> the issue.

The way we are actually seeing this is:
- there are jdk8 jtreg tests that set the
property.  Grepping:


- we have local modifications to classloading that happen to use TLR
via ConcurrentSkipListMap - a "reasonable" thing to do.  Probably the
simplest way to provoke a failure is to try to use a TLR from e.g.

In general, any core library boot class should try hard to avoid
loading/invoking code from the user's classpath.

> It may be another example to back a suggestion to just drop the
> JDK-internal name service provider mechanism. But in general, I think you
> are right, it's not good for TLR initialization to trigger arbitrary code
> to execute.
> -Alan.

More information about the core-libs-dev mailing list