SocketPermissionCollection adds SocketPermission at the head of its internal list. This change was made in jdk 1.2.2_005 bug 4301064 related to reverse dns lookup delays for applets.
This indicates that the tail of the last policy file parsed, is added last to the policy and hence at the head of that List. It's also worth noting that the standard policy provider included with the jvm is in force until the preferred policy provider is completely initiated, after reading all policy files. So it's likely that the standard java policy is read last by our policy provider implementation. In summary a list of SocketPermissions need to be sorted beginning from those that cause long dns delays, to wildcard based permissions, so the wildcard perms are added last and hence checked first by any implies calls. I've got two options on how to solve this: 1. Get rid of PermissionCollection based caches altogether and generate PermissionCollection's on demand. 2 Replace the PermissionCollection cache with a List<Permission> based cache, generate Permissioncollection's on demand. Sort the List after creation, before publishing, replace the list on write. Option 2 could be implemented in ConcurrentPermissions, a replacement for java.security.Permissions. Option 1 would be implemented by the policy. In addition, to allow the security manager to cache the results of permission checks for SocketPermission, I can create a wrapper class, where equals and hashcode are based purely on the string representation. This allows very rapid repeated permission checks. Looks like I can get around the SocketPermission, CodeSource and URL headaches, relatively unscathed. N.B. Anyone care to try out, or seriously performance test the new PreferredClassProvider? Cheers, Peter. ----- Original message ----- > Actually, more significantly for me is that the default localhost > SocketPermission is checked before a more lenient SocketPermission. In theory, > one should be able to introspect SocketPermission instances and determine that > one may be automatically implied by the other so can be skipped, possibly > saving > a lookup. Chris > > Peter Firmstone wrote: > > A big problem with the current implementation is SocketPermission blocks > > other permission checks from proceeding.
