There's another way around poorly written equals() and hashCode()
implementations.
In my reference collection utilities, I have strong, weak and soft
references, there are variations on these based on identity or equality.
Well, I've just thought of another that might help out when poor equals
implementations exist:
toString()?
first check both objects have the same class, then compare the results
of toString(), and use toString().hashCode() for hashCode's.
I could call this String equality, when toString isn't overridden it
prints the reference address so this is compatible with identity based
equality also.
This would fix all those nasty equals implementations for use in
collections without requiring any work on the developers part.
Cheers,
Peter.
Peter wrote:
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.
