JDK-6826789 : SecureClassLoader should not use CodeSource URLs as HashMap keys
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 6,7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-04-06
  • Updated: 2016-08-26
  • Resolved: 2015-06-12
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 9
9 b70Fixed
Related Reports
Relates :  
JDK-8131486 - SecureClassLoader key for ProtectionDomain cache also needs to take into account certificates
Relates :  
JDK-6797730 - Umbrella: Applet startup performance improvements
Relates :  
JDK-7007005 - RFE: startup time of applets suffers if java.policy contains many grant statements
Relates :  
JDK-6826801 - JarFileFactory should not use HashMap
Relates :  
JDK-7152564 - Improve CodeSource.matchLocation(CodeSource) performance
Relates :  
JDK-6810437 - URL.hashcode() and URL.equals() are greedy with DN lookups
Relates :  
JDK-8062948 - Implement and measure potential performance improvements
Description
SecureClassLoader.getProtectionDomain uses HashMap<CodeSource> to cache protection domains to speed up their construction. CodeSource.hashCode() uses URL.hashcode() and CodeSource.equals() uses URL.equals(). 
However, these URL may cause DNS lookups which are expensive if everything is cached. 

We should avoid them, e.g. by using URI.
Comments
It turns out that fixing this is straightforward by converting the URL to a String (using sun.net.util.URLUtil.urlNoFragString) and using that as a key to the HashMap. It does mean that URLs that are equivalent after name resolution may be placed in separate ProtectionDomains, but it is not a compatibility or security issue because the URLs will later be canonicalized (and resolved through the name service) by the Policy provider implementation before granting permissions.
23-03-2015
Changing to an enhancement, since this is a performance enhancement.
30-09-2013
EVALUATION This is difficult to fix without breaking compatibility. For example, the following two CodeSource URLs could be equal after name resolution: http://xxx.yyy.foo.com http://xxx.yyy Changing this could break a bunch of stuff as these CodeSources would now be placed into separate ProtectionDomains. It's possible we may be able to look at this from a different angle, and only do name resolution if a CodeSource is granted something other than AllPermission or the default sandbox permissions, or whenever policy processing is enabled in Plugin (usePolicy=true). But I need to think about it some more.
11-09-2009