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
