On Sun, 17 Oct 2021 15:55:59 GMT, Aleksei Efimov wrote:
> > So Suggestion is refector remove Configuration to simplify the interface
> > and provide the BULITIN_RESOLVER and hostname as parameters to the
> > InetAddressResolverProvider::get method
>
> During work on this JEP we've examined the
On Sun, 17 Oct 2021 16:33:57 GMT, Aleksei Efimov wrote:
> > What’s in a name? I find the method names of the InetAddressResolver
> > interface a bit ambiguous. Typically in this DNS problem space one speaks
> > of lookup to resolve a hostname to its associated addresses and reverse
> > lookup
Hello,
I think the occurrence of the placeholder for process method in
AbstractProcessor is innocuous. It doesn't result an a javadoc entry
with the configuration options for the JDK doc build.
While looking at the class, I noticed some place where @Override could
be used:
https://gith
On Sun, 17 Oct 2021 15:55:59 GMT, Aleksei Efimov wrote:
> * `InetAddressResolverProvider.Configuration` interface API might evolve,
> e.g. there might be a need to pass additional configuration items.
> * local hostname is a dynamic information, therefore it cannot be passed as
> string paramet
On 17/10/2021 04:24, Bernd Eckenfels wrote:
Looking at the code some more I wonder:
* if defaultThreadFactoty should use a Thread group for the pool or
at least for NIO?
* If it can skip the security manager check and use InnocousThread
in all cases (to avoid ThreadLocals - not sure
On Sat, 16 Oct 2021 10:48:32 GMT, Mark Sheppard wrote:
> What’s in a name? I find the method names of the InetAddressResolver
> interface a bit ambiguous. Typically in this DNS problem space one speaks of
> lookup to resolve a hostname to its associated addresses and reverse lookup
> to resolv
On Sat, 16 Oct 2021 12:30:44 GMT, Mark Sheppard wrote:
> So Suggestion is refector remove Configuration to simplify the interface and
> provide the BULITIN_RESOLVER and hostname as parameters to the
> InetAddressResolverProvider::get method
During work on this JEP we've examined the approach s
