On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov <aefi...@openjdk.org> wrote:
>> This change implements a new service provider interface for host name and >> address resolution, so that java.net.InetAddress API can make use of >> resolvers other than the platform's built-in resolver. >> >> The following API classes are added to `java.net.spi` package to facilitate >> this: >> - `InetAddressResolverProvider` - abstract class defining a service, and >> is, essentially, a factory for `InetAddressResolver` resolvers. >> - `InetAddressResolverProvider.Configuration ` - an interface describing the >> platform's built-in configuration for resolution operations that could be >> used to bootstrap a resolver construction, or to implement partial >> delegation of lookup operations. >> - `InetAddressResolver` - an interface that defines methods for the >> fundamental forward and reverse lookup operations. >> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the >> characteristics of one forward lookup operation. >> >> More details in [JEP-418](https://openjdk.java.net/jeps/418). >> >> Testing: new and existing `tier1:tier3` tests > > Aleksei Efimov has updated the pull request incrementally with two additional > commits since the last revision: > > - Add @since tags to new API classes > - Add checks and test for empty stream resolver results test/jdk/java/net/spi/InetAddressResolverProvider/providers/recursive/recursive.init.provider/impl/InetAddressUsageInGetProviderImpl.java line 38: > 36: String localHostName; > 37: try { > 38: localHostName = InetAddress.getLocalHost().getHostName(); Try to call InetAddress.getLocalHost().getHostName(); twice here. test/lib/jdk/test/lib/net/IPSupport.java line 88: > 86: } catch (SocketException se2) { > 87: return false; > 88: } The implementation of this method now conflicts with its name. Maybe we should pass a `Class<? extends InetAddress>` as parameter, and construct the loopback address from there. IIRC the issue with the original implementation was that it would say that IPv6 was not supported if IPv6 had only been disabled on the loopback interface - and that caused trouble because the native implementation of the built-in resolver had a different view of the situation - and saw that an IPv6 stack was available on the machine. Maybe this would deserve a comment too - so that future maintainers can figure out what we are trying to do here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5822
