IMHO, workarounds like this are asking for trouble. You're assuming certain rational actions (a decent toString) on behalf of some other programmer in the presence of evidence that says they aren't rational - i.e. they have a poor equals and/or a poor hashCode implementation.
Combine that with putting the mechanism "under the covers" and I feel that's a nasty piece of dark magic brewing that'll give us problems later. An explicit workaround option is supported in typical collections via a Comparator, yes, that means others have to write some code but it also means the troubles they're facing with equals and hashCode are "in your face". Happy Christmas, Dan. On 23 December 2011 02:06, Peter Firmstone <j...@zeus.net.au> wrote: > 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. >>>> >> >> >> >> > >
