On Sat, 23 Sep 2023 17:28:55 GMT, Aleksei Efimov <[email protected]> wrote:
>> ### Summary >> >> The changes in this PR add new API to `java.net.InetAddress`, >> `java.net.Inet4Address`, and >> `java.net.Inet6Address` classes to parse IP address literals: >> ``` >> method public static java.net.InetAddress >> java.net.InetAddress.ofLiteral(java.lang.String) >> method public static java.net.Inet4Address >> java.net.Inet4Address.ofLiteral(java.lang.String) >> method public static java.net.InetAddress >> java.net.Inet6Address.ofLiteral(java.lang.String) >> ``` >> >> ### How new methods differ from existing ones >> >> These methods differ from `InetAddress.getByName` and >> `InetAddress.getAllByName` in the following ways: >> 1. If a string supplied is not an address literal it is not forwarded to the >> system-wide resolver, but IllegalArgumentException is thrown instead. The >> system-wide resolver is never called from these new methods. >> 2. No reverse lookup is performed to resolve a hostname for the supplied >> address literal - the `InetAddress[46 ]` instances returned by the new >> `ofLiteral` API has no hostname set. >> 3. Each `ofLiteral` static method returns addresses of its class only. It >> gives the ability to check if an IP address literal is of a specific address >> type. >> >> ### The list of noteworthy changes >> - `IPv4-mapped IPv6 address` and `IPv4-compatible IPv6 addresses` require >> some special handling in the new API to implement all supported IP address >> types. >> - All address literal parsing code has been moved from >> `InetAddress.getAllByName` to address type-specific >> `Inet4Address.parseAddressString` and `Inet6Address.parseAddressString` >> methods. >> - The text with scoped IPv6 addresses architecture draft IETF file has been >> replaced from `[draft-ietf-ipngwg-scoping-arch-04.txt]` to reference `RFC >> 4007: IPv6 Scoped Address Architecture`. The "RFC 4007" has been also added >> as `@ spec` into Inet6Address class-level Javadoc. >> >> ### Testing >> >> `jdk-tier1`, `jdk-tier2`, and `jdk-tier3` test sets show no failure with the >> changes. >> >> `java/net` JCK tests are failing with new methods added failure (CSR is >> planned for this change): >> >> Added Methods >> ------------- >> >> java.net.Inet4Address: method public static >> java.net.Inet4Address java.net.Inet4Address.ofLiteral(java.lang.String) >> java.net.Inet6Address: method public static >> java.net.InetAddress java.net.Inet6Address.ofLiteral(java.lang.String) >> java.net.InetAddress: method public static >> java.net.InetAddress java.net.InetAddress.ofLiteral(java.lan... > > Aleksei Efimov has updated the pull request incrementally with two additional > commits since the last revision: > > - updates for Inet6Address.ofLiteral return type, javadoc and the regression > test > - add null checks and NPE to methods javadoc the most consistent (with the current API) and object oriented version is the getByAddress(String addr). It is consistent with the existing API. Logically getByAddress(byte[]) and getByAddress(String) are essentially the same. That is to say, a literal string representing an address is essentially the same as an array of bytes representing an address, as a String is an encapsulation of an array of bytes. As such it logically natural to add an overloaded method. Adding a new style of method affects the logical balance of the InetAddress class, giving a mongrel, or hybrid API appearance. Ceist agam ort: Why is it necessary that the subclasses Inet4Address and Inet6Address have an explicit public method for a getByAddress approach? Or have I misconstrued your statement: "Overrides existing method in InetAddress, but adds new method to Inet4Address and Inet6Address." ? But this is the case for the current "ofLiteral" solution presented in the PR, in that each of the derived classes Inet4Address and Inet6Address have added new static public methods. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1749739710
