<!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>