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 thanks for the considered response > > That is to say, a literal string representing an address is essentially the > > same as an array of bytes representing an address > > A literal IP address string can specify the same address in [multiple > formats](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/InetAddress.html#textual-representation-of-ip-addresses-heading), > a byte array supports only one - an array of bytes, with length equal to 4 > for IPv4 addresses, and to 16 for IPv6 addresses. I think you may have misinterpreted the point I was trying to make (or I didn't make it clearly enough), for example, a 4 byte array representing an IPv4 address is logically the same as a String representing an IPv4 address in dot notation. Thus, overloading getByAddress is a reasonable method to add and exhibits OO characteristics. > > > Ceist agam ort: > > Why is it necessary that the subclasses Inet4Address and Inet6Address have > > an explicit public method for a getByAddress approach? > > The idea of this change is to add three methods capable of parsing a string > as an IPv4, IPv6 or any IP literal address. The explicit methods need to be > added to all three classes irrelevant to their naming. > > > 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. > > You are right that the statement is a bit vague, yes. What was meant there > was overloading the `InetAddress` method, and adding new methods to > `Inet4Address` and `Inet6Address` would introduce a bit confusing API > structure. All three classes for both approaches would look like: > ### ofLiteral approach > > ``` > // New methods > InetAddress.ofLiteral(String) > Inet4Address.ofLiteral(String) > Inet6Address.ofLiteral(String) > ``` > > ### getByAddress approach > > ``` > // Existing methods with `address` being a byte array > InetAddress.getByAddress(String, byte[]) > InetAddress.getByAddress(byte[]) > > // New methods with `address` being a literal > InetAddress.getByAddress(String) <-- overloaded method > Inet4Address.getByAddress(String) <-- new and not overloaded method > Inet6Address.getByAddress(String) <-- new and not overloaded method > ``` There's no need to add these methods, Inet4Address.getByAddress(String) <-- new and not overloaded method Inet6Address.getByAddress(String) <-- new and not overloaded method to the derived classes. The functionality can be fully provided by the overloaded (static) getByAddress in the base InetAddress class ------------- PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1751688344
