Hello Core Libs Dev team,
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
(|inet_addr|) 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 |InetAddress| object from such literal
addresses because the new API |InetAddress.ofLiteral()| and
|Inet4Address.ofLiteral()| 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.
Historically |InetAddress.getByName()/.getAllByName()| were the only way
to convert a literal address into an InetAddress object.
|getAllByName()| API relies on POSIX |getaddrinfo| / |inet_aton| which
parses IP address segments with |strtoul| (accepts octal and hexadecimal
bases). The fallback to |getaddrinfo| is undesirable as it may end up
with network queries (blocking mode), if |inet_aton| rejects the input
literal address. The Java standard explicitly says that
|"If a literal IP address is supplied, only the validity of the address
format is checked." |
Aleksei Efimov contributed JDK-8272215 [2] that adds new factory methods
|.ofLiteral()| to |InetAddress| classes. Although the new API is not
affected by the |getaddrinfo| fallback issue, it is not sufficient for
an app that wants to mimic the behavior of BSD/POSIX network utlilities.
It is suggested to add a new factory method such as |.ofPosixLiteral()|
to |Inet4Address| 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 |InetAddress| 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.
Please share your thoughts on whether such a change might be desirable
in JDK 23.
Thank you for your help!
Best regards
Sergey Chernyshev
[1] https://bugs.openjdk.org/browse/JDK-8315767
[2] https://bugs.openjdk.org/browse/JDK-8272215
