JDK-6826780 : URLClassPath should use HashMap instead of HashMap
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-04-06
  • Updated: 2010-04-04
  • Resolved: 2009-08-14
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.

To download the current JDK release, click here.
JDK 6 JDK 7
6u18Fixed 7 b70Fixed
Related Reports
Relates :  
JDK-6826801 - JarFileFactory should not use HashMap
Relates :  
JDK-6797730 - Umbrella: Applet startup performance improvements
Relates :  
JDK-6810437 - URL.hashcode() and URL.equals() are greedy with DN lookups
Description
URL.hashcode() will cause DNS lookup (see 6810437) and this might be very noticeable if eveything is taken from disk cache (e.g. deployment cache). 

Suggested solution is to use URI instead of URL.
Comments
EVALUATION changeset: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0d99696fec64
07-08-2009
EVALUATION Webrev: http://cr.openjdk.java.net/~chegar/6826780/webrev.00/webrev/ 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. Compatibility concerns: 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 very often. 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.
07-08-2009
EVALUATION Requires detailed analysis to assess the compatibility and security implications. Too risking for an update release.
07-04-2009