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 ). > On 28 Mar 2020, at 06:43, Jaikiran Pai <jai.forums2...@gmail.com> 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() which now reads[4]: > > "... > > If the address is unresolved, <unresolved> is displayed in place of the > address literal. > > " > > Previously, until as recent as Java 13[5], it used to be: > > "... > If the address is unresolved then the part before the colon will only contain > the hostname. > > " > > 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. > 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. > 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. Can we check if the most recent ZooKeeper is still calling toString, using getHostString, or doing something else? -Chris.
