RFR: JDK-6826789: SecureClassLoader should not use CodeSource URLs as HashMap keys

[Sean Mullan]

On 6/11/15 11:33 AM, Weijun Wang wrote:
> Hi Sean
>
> I remember you mentioned that although no name lookup is performed here
> the permissions will be calculated correctly, even if they are granted
> to different host strings which are actually equivalent (your new test
> proves this). The URL strings still must be resolved somewhere else to
> make this happen. Can you add a comment on where?

Yes, I can do that, and there is some info in the bug about this. 
Basically, the CodeSource URL will be canonicalized (and resolved 
through the name service if applicable) by the policy provider when 
determining what permissions to grant (at this point it will call 
CodeSource.implies which will trigger it). So you still may take a 
performance hit at some point, but only if a permission check is needed. 
I should have also pointed out that this improvement benefits apps that 
don't have a SecurityManager enabled (the startup/loading of classes 
should be faster).

--Sean

>
> Thanks
> Max
>
> On 06/11/2015 09:54 PM, Sean Mullan wrote:
>> This is the fifth in a series of fixes for JEP 232 (Improve
>> Secure Application Performance) [1].
>>
>> webrev:
>> http://cr.openjdk.java.net/~mullan/webrevs/6826789/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-6826789
>>
>> This fix changes the keys used in the ProtectionDomain cache in
>> SecureClassLoader from URLs to Strings. The URL.hashCode method can
>> trigger a potentially expensive name service lookup. The String form of
>> the URL avoids that lookup, resulting in a big performance improvement.
>>
>> Thanks,
>> Sean
>>
>> [1] http://openjdk.java.net/jeps/232