On Mon, 18 Sep 2023 17:16:41 GMT, Daniel Fuchs <[email protected]> wrote:
>> This method behaves like `InetAddress.getByName` in that regards. > > I believe accepting leading 0 as an octal indicator would require a new API, > yet to be defined. What we're proposing here is a method that behaves like > `InetAddress.getByName` would except that it rejects what > `InetAddress.getByName` would have identified as a hostname needing > resolution. In other words it only accepts IP literals that > `InetAddress.getByName` would accept as IP literals, and parses them as > `InetAddress.getByName` would parse them, and rejects anything that would > cause `InetAddress.getByName` to invoke the resolver. > if we ignore octal encoding, we should document it explicitely. Agree - Javadoc for `Inet4Address.ofLiteral` needs to be updated to cleary mention that only IPv4 literals in decimal encoding are supported, and to state that no other encodings (octal, hexadecimal) are supported. That will also need to mention that one, two, three and four-part IPv4 address literals are supported to match [Inet4Address format section](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/Inet4Address.html#format) > Maybe > > > The loose IPv4 syntax of partial numbers or hex encoding ("10.0.258", > > "0xA000102") is > > not supported and causes a parsing error. Octal (zero) > > prefixes are ignored, i.e. interpreted decimal. Thanks for the suggestion. `10.0.258` is supported and [documented](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/Inet4Address.html#format) 'd.d.d' format. It is not planned to change support for such address. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15775#discussion_r1330043596
