From https://github.com/belaban/JGroups/discussions/725#discussioncomment-7388708:

I can confirm this issue. Starting with version 5.2.0 the instantiation time for a JChannel grew from <1s to 12s. In our stack configuration we have all bind_addr and other address related fields explicitly set, but nevertheless a call to Util.getNonLoopbackAddress is performed in Configrator.setDefaultAddressValues. This call seems to be slow with certain network configurations on some machines.
It didn't hurt much in versions prior to 5.2.0, because Util.getNonLoopbackAddress was called only once for the whole stack, but now it is called once for each protocol in the stack, even if the particular protocol does not have any address related fields. I think a lazy computation of the non-loopback address only when needed, including caching, would speed this up significantly.