[concurrency-interest] ThreadLocalRandom clinit troubles

Peter Levart peter.levart at gmail.com
Fri Jun 20 07:20:18 EDT 2014


On 06/20/2014 11:10 AM, Peter Levart wrote:
> Perhaps a more lazy initialization of NetworkInterface class that does 
> not trigger initialization of NS providers could help. We just need to 
> invoke two methods on NetworkInterface:
>
> - static NetworkInterface.getNetworkInterfaces()
> - instance NetworkInterface.getHardwareAddress()
>
> both of which could provide the result without the need of NS 
> providers, I think.
>
> This would solve the most general case of using TLR. The case that 
> doesn't involve SecureRandom's help which I think is rarely needed and 
> not default.
>
>
> Regards, Peter 

Hi,

A patch that solves this is a patch to InetAddress. We can't suppress 
initialization of InetAddress as part of NetworkInterface 
initialization, but we can suppress initialization of NameService 
providers as part of InetAddress initialization by moving them into a 
nested class called NameServices:

http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.NameServices/webrev.01/

This should solve Martin's issue, but the patch to TLR initialization 
could be applied nevertheless, since it might help overcome possible 
issues when using SecureRandom for TLR's seed.

Regards, Peter



More information about the Concurrency-interest mailing list