On 01/04/20 3:49 pm, Julia Boes wrote:
>
> Hi Jaikiran,
>
>>>> 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.
>>
> Based on the feedback, we updated the related release note to better
> explain "literal IP address" and to include a pointer to
> InetSocketAddress::getHostString.
>
> https://www.oracle.com/technetwork/java/javase/14all-relnotes-5809668.html#JDK-8225499
>
Thank you Julia - that's descriptive enough, IMO.-Jaikiran
