On Thu, Dec 7, 2017 at 8:32 AM, Chris Hegarty <chris.hega...@oracle.com> wrote: > David, > > On 07/12/17 13:14, David Lloyd wrote: >> >> On Thu, Dec 7, 2017 at 5:53 AM, Alan Bateman <alan.bate...@oracle.com> >> wrote: >>> >>> This thread is getting a little off-topic but... >> >> >> Getting it back on topic again: >> >>> Proposal for the standard module name: java.net.httpclient. Proposal for >>> the standard package name: java.net.http. >> >> >> I think it would be better if both the module and the package were >> "java.net.http.client", for two reasons. Firstly, it is important to >> align the package and module name whenever possible; I don't think >> there's a compelling reason here (or most anywhere else) not to do so. >> Secondly, it is not unreasonable to expect that the future may bring >> other HTTP-related APIs that are not necessarily client-specific. >> >> Relatedly, it may be wise to rename "HttpRequest" and "HttpResponse" >> to "HttpClientRequest" and "HttpClientResponse", respectively. > > > I agree that symmetry between the module name and package name is > desirable. If the module / package name contains `client`, then it is > effectively redundant in the type name ( unless there are many types > being imported from other unrelated HTTP libraries ).
HttpRequest and HttpResponse are very common names for both client and server libraries. I would not consider it odd for a server to have HttpRequest for incoming requests; if the client also uses HttpRequest for its outbound requests, then a bunch of annoying qualification will be going on. It seems redundant, but the namespacing of the package and the class serve different purposes: the package is to reserve space for other specs, the class is to avoid conflict with servers. > The JEP does make a proposal on the module and package name, but I think > a discussion on naming will be needed. I'm not sure that we need to > decide that now, but your point has been noted. OK. -- - DML
