JDK-6826780 : URLClassPath should use HashMap instead of HashMap
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
The general idea is to replace the use of URL as a key in HashMap/Set with a String representation. The String form should behave in the same manner as URL when compared for equality in a HashMap/Set, except that no nameservice lookup is done on the hostname (string comparison only), and the fragment is not considered.
The default URLStreamHandler equals method compares the string protocol (case-insensitive), port or default port (if there is one), IP address of the hosts or host string (case-insensitive) if IP cannot be retrieved, the file, and the fragment. Ignoring the fragment (not actually relevant) and IP address, the other components are just strings, so if we build a urlString form from these component in a consistent way we should be able to do a string comparison (within the HashMap/Set) and get a similar result to that of URL.equals.
1) fragment is no longer being used. Two same URL's with different
fragments will now be considered the same, i.e. you will not get a
separate loader for each. This is not a problem since the URL's
actually refer to the same file.
2) Two same URL's in some circumstances may not be equal, if DNS round
robin used to load balance across multiple servers. Before this
change a new loader is created for each URL, now the URL's are
considered equal and only one loader will be created. This should not
be a problem as both URL's should refer to the same file anyway.
In fact, this change could be considered an optimization.
3) Two same URL's except different hosts, but hosts resolve to the same
IP address. Before the change only a single loader will be created.
After the change two loaders will be created. This should not be a
problem, a little inefficient, but we would not expect this to happen
These changes alone will not completely remove the code source/resources nameservice lookups in the case of plugin/webstart, but there are other optimizations around indexing of jars that may result in the loader for a particular url being created but the jar not actually being downloaded if it is known (from a jar index elsewhere) that the jar does not contain the required resource. So we may want to avoid the lookup until absolutely necessary.
Requires detailed analysis to assess the compatibility and security implications. Too risking for an update release.