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

[Alan Bateman]

On 28/03/2020 06:43, Jaikiran Pai wrote:
>
> There's an issue raised in Quarkus repo[1], where Apache Kafka 
> (embedded) no longer starts on Java 14. From what I can see the root 
> cause is this[2].
>
> JDK-8225499[3] changed the implementation (and even the javadoc) of 
> the InetSocketAddress.toString()
>
For the Quarkus/Kafka issue, do you know if it really needs to parse the 
String representation? Just curious why it doesn't use getHostString. To 
my knowledge anyway, this is the first report of an issue with this 
spec/implementation change. It's a reminder that we need a lot more 
testing of the JDK early access builds to gauge the impact of fixes like 
this.

As I think you've found, the spec/implementation change in Java SE 14 
has two parts.

The change to surround an IPv6 literal address (and maybe the scope ID) 
in square brackets. Anything that parses a string that encodes an IP 
address and port, say the host component in a URI string, will have seen 
this already.

The change to concatenate "/<unresolved>" to unresolved addresses. I 
think it's important to observe that an InetSocketAddress can be created 
with nonsensical input so it's easy to confuse code that parses the 
string representation, e.g. new InetSocketAddress("java.com/1.2.3.4", 
80) creates an InetSocketAddress that is unresolved but its string 
representation (when run on JDK 13 or older) would suggest otherwise. 
I'll have to defer to Julia, Daniel and Chris to see what other options 
were considered. I could imagine conditionally adding ""/<unresolved>"  
based on whether host string contains slash and/or colon characters. 
That might reduce the compatibility impact but at the cost of additional 
complexity and/or non-obvious failures in code that encounter 
nonsensical string on rare occasions.

-Alan