URLStreamHandler.getHostAddress() performance

[Pavel Rappo]

> On 25 Nov 2014, at 14:03, Mark Sheppard <mark.sheppard at oracle.com> wrote:
> 
> I think this raises  a more fundamental question, as to why   the URL hashCode()  and equals() methods  delegates to URLStreamHandler
> in the first place? rather than performing the processing within the URL class itself, and synchronizing appropriately within.

Mark, I guess it's a part of initial design. Handlers know how to parse each individual URL (URLStreamHandler::parseURL), they know how to split URL into meaningful components. They know what these components mean. Therefore they were probably chosen as the best place calculate hash code and perform equality test.
But that's in theory. In practise we have a purely-defined URL::equals and URL::hashCode

> If you call equals() and hasCode() concurrently on the same URL instance, there exists the possibility (slight) that
> the hostAddress could be set differently, when it is being set for the first time, without the synchronization of the getHostAddress() in the URLStreamHandler.
> 
> Although it may rarely happen the mechanics of InetAddress.getByName() potentially,  lend itself to a different return address
> on multiple calls, as it returns the first address from a array of addresses retrieved - assumption is that the ordering will always be the same.
> 
> regards
> Mark

Agreed. Correct me if I'm wrong, I believe InetAddress::getByName is inherently inconsistent since a naming service is involved.