ThreadLocalRandom clinit troubles

[Alan Bateman]

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(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.
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. 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.