InetAddress API extension proposal

[Sergey Chernyshev]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240326/4aedad99/attachment.htm>