On Fri, 4 Aug 2023 13:01:00 GMT, Jaikiran Pai <[email protected]> wrote:
>> Can I please get a review of this change which updates the javadoc of >> `java.net.InetAddress.getCanonicalHostName()` method to clarify its >> semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239. >> >> This a javadoc only change and the documentation is updated to match the >> current implementation. A CSR will be drafted for this change. > > Jaikiran Pai has updated the pull request incrementally with one additional > commit since the last revision: > > Aleksei's review src/java.base/share/classes/java/net/InetAddress.java line 792: > 790: * {@linkplain InetAddressResolver resolver}. > 791: * > 792: * <p>The system-wide resolver will be used to do a reverse name > lookup of the IP address. The wording in this paragraph seems a bit different to getHostName and I think we should try to use the same terms in both methods if possible, e.g. getHostName talks about the "system configured resolver" where here it uses "system-wide resolve". We have have "used" vs. "performed". So maybe look at the methods again as I think we should be a bit more consistent with the wording if we can. src/java.base/share/classes/java/net/InetAddress.java line 796: > 794: * service. In such cases, where the resolver isn't able to > determine the fully qualified > 795: * domain name, this method returns the {@linkplain > #getHostAddress() textual representation} > 796: * of the IP address. I think it would be better to say that the lookup can fail for many reasons that include the host not being registered with the name service. A suggestion for "In such cases .." is to say "f the resolve is unable to determine ...". I think that would be a bit easer to read. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1287096421 PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1287098493
