United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6826780 URLClassPath should use HashMap<String, XXX> instead of HashMap<URL, XXX>
6826780 : URLClassPath should use HashMap instead of HashMap

Details
Type:
Bug
Submit Date:
2009-04-06
Status:
Resolved
Updated Date:
2010-04-04
Project Name:
JDK
Resolved Date:
2009-08-14
Component:
core-libs
OS:
generic
Sub-Component:
java.net
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:
7

Related Reports
Backport:
Relates:
Relates:
Relates:

Sub Tasks

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
                                     
2009-08-07
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.
                                     
2009-08-07
EVALUATION

Requires detailed analysis to assess the compatibility and security implications. Too risking for an update release.
                                     
2009-04-07



Hardware and Software, Engineered to Work Together