[concurrency-interest] ThreadLocalRandom clinit troubles

Peter Levart peter.levart at gmail.com
Fri Jun 20 10:02:27 EDT 2014


On 06/20/2014 03:00 PM, Alan Bateman wrote:
> On 20/06/2014 12:20, Peter Levart wrote:
>>
>> 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.
> That should work. An alternative is to just get rid of this mechanism. 
> Way back then it was useful for running on systems that has NIS/YP 
> configured as it wasn't always possible get to the fully qualified 
> host name. It was also used as a workaround to long timeouts on 
> Windows doing NetBIOS lookups. I don't think if either of these cases 
> it interesting these days so it might be the simplest thing to just 
> get rid of it. The other thing is that it was never meant to be a 
> general service provider mechanism, it's not usable outside of the JDK 
> without extending JDK-internal classes for example.
>
> -Alan

And, as Martin pointed out, it seems to be used for tests that exercise 
particular responses from NameService API to test the behaviour of JDK 
classes. It would be a shame for those tests to go away.

Regards, Peter



More information about the Concurrency-interest mailing list