ThreadLocalRandom clinit troubles
Peter Levart
peter.levart at gmail.com
Fri Jun 20 14:02:27 UTC 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 core-libs-dev
mailing list