On Thu, 5 Oct 2023 22:25:23 GMT, Mark Sheppard <mshep...@openjdk.org> wrote:
> 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. > 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 ------------- PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1750435491
