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