> On 25 Nov 2014, at 14:03, Mark Sheppard <mark.shepp...@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.
