<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello Core Libs Dev team, </p>
<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="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="notranslate">InetAddress</code> object
from such literal addresses because the new API <code
class="notranslate">InetAddress.ofLiteral()</code> and <code
class="notranslate">Inet4Address.ofLiteral()</code> will consume
an 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.</p>
<p dir="auto">Historically <code class="notranslate">InetAddress.getByName()/.getAllByName()</code>
were the only way to convert a literal address into an InetAddress
object. <code class="notranslate">getAllByName()</code> API
relies on POSIX <code class="notranslate">getaddrinfo</code> / <code
class="notranslate">inet_aton</code> which parses IP address
segments with <code class="notranslate">strtoul</code> (accepts
octal and hexadecimal bases). The fallback to <code
class="notranslate">getaddrinfo</code> is undesirable as it may
end up with network queries (blocking mode), if <code
class="notranslate">inet_aton</code> rejects the input literal
address. The Java standard explicitly says that</p>
<div
class="snippet-clipboard-content notranslate position-relative overflow-auto">
<pre class="notranslate"><code class="notranslate">"If a literal IP address is supplied, only the validity of the address format is checked."
</code></pre>
<div
class="zeroclipboard-container position-absolute right-0 top-0">
</div>
</div>
<p dir="auto">Aleksei Efimov contributed JDK-8272215 [2] that adds
new factory methods <code class="notranslate">.ofLiteral()</code>
to <code class="notranslate">InetAddress</code> classes. Although
the new API is not affected by the <code class="notranslate">getaddrinfo</code>
fallback issue, it is not sufficient for an app that wants to
mimic the behavior of BSD/POSIX network utlilities.</p>
<p dir="auto">It is suggested to add a new factory method such as <code
class="notranslate">.ofPosixLiteral()</code> to <code
class="notranslate">Inet4Address</code> class to fill this gap.
This won't introduce ambiguity into the API and won't break the
long standing behavior. I am not sure if the superclass <code
class="notranslate">InetAddress</code> needs the new method too
because the change is only related to IPv4 addressing, also the
chance that client code will call the wrong factory method is
reduced when it knows exactly what it does.</p>
<p></p>
<p dir="auto">Please share your thoughts on whether such a change
might be desirable in JDK 23.</p>
<p dir="auto">Thank you for your help!<br>
</p>
<p dir="auto">Best regards<br>
Sergey Chernyshev</p>
<p dir="auto">[1] <a class="moz-txt-link-freetext"
href="https://bugs.openjdk.org/browse/JDK-8315767">https://bugs.openjdk.org/browse/JDK-8315767</a><br>
[2] <a class="moz-txt-link-freetext"
href="https://bugs.openjdk.org/browse/JDK-8272215">https://bugs.openjdk.org/browse/JDK-8272215</a><br>
</p>
</body>
</html>