<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi David,<br>
Thank you for your comments.<br>
</p>
<div class="moz-cite-prefix">Am 28.03.24 um 21:09 schrieb David
Lloyd:<br>
</div>
<blockquote type="cite"
cite="mid:CANghgrRp0V4JV_00eztY1FeATNDwNcUZKjxisAF-B=+P_8R8iw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><br>
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>I would like to propose a PR to extend the InetAddress
API in JDK 23, namely to provide interface to
constructing InetAddress objects from literal addresses
in POSIX/BSD form (please see the discussion [1]), to
the Apps that need to mimic the behavior of POSIX
network APIs (<code class="gmail-notranslate">inet_addr</code>)
used by standard network utilities such as
netcat/curl/wget and the majority of web browsers. At
present time, there's no way to construct <code
class="gmail-notranslate">InetAddress</code> object
from such literal addresses because the new API <code
class="gmail-notranslate">InetAddress.ofLiteral()</code>
and <code class="gmail-notranslate">Inet4Address.ofLiteral()</code>
will consume an octal address and successfully parse it
as decimal, ignoring the octal prefix. Hence, the
resulting object will point to a different IP address
than it is expected to point to. There's also no direct
way to create an InetAddress from a literal address with
hexadecimal segments, although this can be the case in
certain systems.<br>
</p>
</div>
</blockquote>
<div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">Would this
proposal be unique to IPv4 addresses, or is there an
equivalent for IPv6? (I would suspect that there isn't,
given that the parsing rules for IPv6 are a bit more
well-defined...)</div>
</div>
</div>
</div>
</blockquote>
<p>Yes this is IPv4 specific.<br>
</p>
<blockquote type="cite"
cite="mid:CANghgrRp0V4JV_00eztY1FeATNDwNcUZKjxisAF-B=+P_8R8iw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>It is suggested to add a new factory method such as <code
class="gmail-notranslate">.ofPosixLiteral()</code> to <code
class="gmail-notranslate">Inet4Address</code> class to
fill this gap. This won't introduce ambiguity into the API
and won't break the long standing behavior. As a new
method, it will not affect Java utilities such as
HttpClient, nor the existing Java applications. At the
same time, the new method will help dealing with confusion
between BSD and Java standards.</div>
</blockquote>
<div><br>
</div>
<div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">I would
suggest normatively calling this behavior "POSIX standard"
parsing (not BSD or POSIX/BSD), since it (at least
nominally) comes from a standards body [1]. Bear in mind
that `inet_pton` follows different rules though [2]. RFC
6943 [3] has a bit more to say about so called "loose" vs
"strict" IP address parsing rules.</div>
</div>
</div>
</div>
</blockquote>
<p>Thanks, I will put a note on it in the PR and update the
motivation text accordingly.</p>
<blockquote type="cite"
cite="mid:CANghgrRp0V4JV_00eztY1FeATNDwNcUZKjxisAF-B=+P_8R8iw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>There could be a slight <span lang="en"><span><span>discrepancy</span></span></span>
in terms of how different standard tools are working under
different OS. For example in MacOS wget & nc disregard
octal prefix (0) while allowing hexadecimal prefix (0x),
at the same time curl & ping process both prefixes. In
Ubuntu Server 22.04 both prefixes are processed, but they
are not allowed in /etc/hosts file, while in MacOS it's
legal to use 0x. Despite the deviations in how and where
the BSD standard is implemented, there are two distinct
approaches. I don't see why Java should't provide two
different indepentent APIs. It would give the future apps
flexibility to decide which standard to rely on, ability
to see the full picture.<br>
<p dir="auto">Please share your thoughts on whether such a
change might be desirable in JDK 23. Thank you for your
help!</p>
</div>
</blockquote>
<div><span style="font-family:arial,helvetica,sans-serif">I
guess it could be useful when the need arises to
interoperate with tooling that supports this kind of
syntax, and if it was done, I would agree that a separate
method would be the way to go. But, I don't have any
comment as to whether the potential use cases are
sufficient to justify the API surface and additional
implementation complexity (whatever that may be).</span><br>
</div>
</div>
</div>
</blockquote>
<p>This is the primary use case of the proposed API. Implementaions
that rely on inet_addr() syntax are still too widespread to ignore
them.<br>
</p>
<blockquote type="cite"
cite="mid:CANghgrRp0V4JV_00eztY1FeATNDwNcUZKjxisAF-B=+P_8R8iw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">As another
random data point: the projects I've been working on have
relegated such extra-JDK IP address handling tasks to a
utility library [4]. We don't have a parser for this
particular syntax though.</div>
</div>
</div>
</div>
</blockquote>
<p>I think Guava and Apache Commons both have similar utility
classes. Neither of them have that syntax. But I also see
libraries that do have that syntax - an example is IPAddress
library (<a class="moz-txt-link-freetext" href="https://github.com/seancfoley/IPAddress">https://github.com/seancfoley/IPAddress</a>).<br>
</p>
<br>
</body>
</html>