Java 14 - Change in InetSocketAddress.toString() behaviour seems to be causing issues

[Jaikiran Pai]

Hello Chris,

On 30/03/20 1:49 pm, Chris Hegarty wrote:
> Hi Jaikiran,
>
> Thank you for posting this message to net-dev.
>
> TL;DR seems like the specific issue raised against Quarkus has been
> resolved ( by upgrading to a more recent version of ZooKeeper ).

That's correct.

>
>> So this looks like an intentional(?)
>>
> Correct. This is an intentional change, to improve the string
> representation. See the following CSR
> https://bugs.openjdk.java.net/browse/JDK-8232002 
>>
>> breakage in that toString() API semantics?
>>
> FTR - I take exception with the term “breakage” - The change is
> intentional, consideration given to the compatibility impact, and a
> release note published. InetSocketAddress::getHostString was added in
> Java 7 to retrieve the host, or address, string representation.

Sorry about that term, I didn't mean to say that not enough thought was
spent on this change. I merely meant it to mean that the API behaviour
has changed.

>
>> I do see that it did make it to the release notes of this version,
>> but given how conservative Java has been in terms of breaking
>> changes, is this change too quick in introducing such a breaking change?
>>
> No. As above, code should really be using getHostString, which has
> been available since July 2011. I do not consider this too quick.

I agree about the getHostString() API being available since Java 7 days.
What I meant about this possibly being a bit too quick of change is
that, the toString() API of this class, even till Java 13, clearly
states that the part before the colon, of an unresolved address is a
host name. It doesn't however recommend using the getHostString(). So
there could be code which might still be using this API for the
semantics noted in Java 13.

Having said that, I would like to clarify that I don't have anything
against this change. I like that the unresolved address is now more
"visible".

>> By the way, keeping aside the breaking nature of this change, the
>> current javadoc, I think doesn't reflect what the current
>> implementation returns for unresolved addresses. The javadoc states:
>>
>> "If the address is unresolved, |<unresolved>| is displayed in place
>> of the address literal."
>>
>> Note, the "in place of the address literal" part. However, in the
>> current implementation[6], it returns something like -
>> "localhost/<unresolved>:2182". So it doesn't just display the
>> "<unresolved>" literal in the address part but suffixes it to the
>> address part. Should that be clarified?
>>
> The InetSocketAddress string representation defers, partly, to
> InetAddress::toString, which specifies the “hostname / literal IP
> address” form. It is this address literal that is replaced with
> “<unresolved>”. If this is not clear from this spec, then it can be
> clarified.
>
Now that you explained it to me, I see what you mean and what that
javadoc means. I hadn't paid attention to the "This String is
constructed by calling toString() on the InetAddress and concatenating
the port number (with a colon)". Looking at the javadoc on
InetAddress.toString(), it does state the returned string to be of the
form "hostname/literal IP address" (example:
google.com/172.217.160.142). So when it says that "<unresolved> is
displayed in place of the address literal", it actually is talking about
the part that follows the "/" character in the output returned by the
InetAddress.toString().

I'll be honest - I didn't even know that up until this release, the
output of this API was something like google.com/172.217.160.142:80. I
had it in my mind that the output was google.com:80. That's why when the
new javadoc said "in place of the address literal", I thought it was
talking about replacing "google.com" with "<unresolved>"

I don't know if it's just me who couldn't fully understand it until this
was explained. For me, a {@link InetSocket.toString()} in the javadoc
and a couple of example representations of what the output of toString()
would look like would have made it easier. But I do understand that the
javadoc may not be the right place for such level of details.

> Can we check if the most recent ZooKeeper is still calling toString,
> using getHostString, or doing something else?
>
My quick look shows that in the newer version of that library there is
no such call (at least not in the context of using the return value to
get hold of the host string). However, I don't have enough experience
with that library. So I'll raise this in their issue tracker and point
them to this thread and see what they say.

-Jaikiran


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200331/d1ac4bbf/attachment-0001.htm>