RFR: 8272215: Add InetAddress methods for parsing IP address literals

[Mark Sheppard]

On Sun, 17 Sep 2023 13:38:08 GMT, Aleksei Efimov <aefimov at openjdk.org> 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.Inet6Address 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. Address literal strings are not forwarded to the system-wide resolver - they are only parsed and validated by the internal 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.Inet6Address java.net.Inet6Address.ofLiteral(java.lang.String)
> java.net.InetAddress:                   method public static java.net.InetAddress java.net.InetAddress.ofLiteral(java.lang.String)

Looking at the motivation for this addition in the budgd description
The requirement is that of providing a methof to parse of an  string literal address returns and return an InetAddress without necessitating a reverse address lookup, which is what getByName does at the minute.
The additional motivation, appears to be to avoid the  misinterpretation scenario where an invalid address
String literal is considered as a hostname or fqdn resulting in a look by name.

Adding explicit factory methods is one approach, as proposed here. 
An alternative is to provide a string literal validator
which returns true if the string literal address is either an IPv4 or IPv6 address.
The validator can be used by an application in conjunction with the existing API getByName method.
For example, boolean isValidLiteralAddress(String literalAddress)
 InetAddress serverAddress;
 if (InetAddress.isValidLiteralAddress(someLiteralAddress) {
     serverAddress = InetAddress.getByName(someAddress);
 …
 }

This will provide applications with a convenience method to validate inputs and use existing API without side effects.
Also, this approach will reduce the amount of internal restructuring required, should guarantee current behaviour, and provide a convenience application validation method.

But, for some might consider making two method calls  be too much of a burden!

If this is not considered an appropriate option, then a renaming of the proposed methods would be beneficial so as to exhibit the semantics of the operations.
For example, in keeping with the current nomenclature of getByName, getByAddress then getFromLiteral or getByLiteral would be in keeping with current naming scheme.

Alternatively, a straight forward “it does what it says on the tin” name  such as parseLiteral would seem appropriate. I'm not a big fan of these "of" factory methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15775#issuecomment-1722571081