ThreadLocalRandom clinit troubles
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:
>> 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:
>> 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.
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.
More information about the core-libs-dev