New candidate JEP: 418: Internet-Address Resolution SPI

[Aleksej Efimov]

Hi Mark,

Given Alan's input on "name service" term and providers naming convention,  do you still think that we should rename "java.net.spi.InetNameServiceProvider"?
If yes, then maybe it would be better to name classes `InetAddressResolverProvider` and `InetAddressResolver` - it might help to highlight that it is used by `InetAddress` API.

Thanks,
Aleksei

________________________________
From: Alan Bateman <alan.bateman at oracle.com>
Sent: Saturday, September 4, 2021 10:09 AM
To: Mark Reinhold <mark.reinhold at oracle.com>; Aleksej Efimov <aleksej.efimov at oracle.com>
Cc: net-dev at openjdk.java.net <net-dev at openjdk.java.net>
Subject: Re: New candidate JEP: 418: Internet-Address Resolution SPI

On 03/09/2021 22:38, mark.reinhold at oracle.com wrote:
> A suggestion, if I may ...
>
> Consider using the term “resolver” instead of “name service,” especially
> in the names of the SPI classes and interfaces.
>
> That would avoid confusing the service of looking up names and addresses
> with the service of providing a service to look up names and addresses.
> That is, the service you’re defining is a provider of name services,
> i.e., a name service service.  This can lead to many annoying questions.
> Is an instance of the SPI class `InetNameService` a name service, or a
> name service service provider?  Why isn’t the SPI class
> `InetNameServiceProvider` named `InetNameServiceServiceProvider`?
>
> Using “resolver” would let you talk more simply about a “resolver
> service,” and have clear and concise class and interface names (e.g.,
> `InetResolverProvider` and `InetResolver`).
Thanks, it is always useful to get another set of eyes on this. We've
been using "NameService" in all prototypes/exploration to date because
"name service" is the term used in the API docs since around JDK 1.4. It
might mean changing the phrasing in some of the existing API docs.

For service providers then naming convention has mostly been to append
"Provider". I think you are right here, it may be ambiguous or confusing
when appended to "InetNameService". The intention of course was that the
provider class be a factory for InetNameService objects, not "InetName".

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20210909/6e9afb05/attachment.htm>