&quot;darran.lofthouse(a)jboss.com&quot; wrote : But it fails the following two requirements for an equals implementation: - | | anonymous wrote : | | # It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true. | | # It is transitive: for any non-null reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true. | | | | The following requirement from hashCode will also not be met: - | | anonymous wrote : If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result. | | Basically you can not put different principal implementation in a HashMap and expect consistent behaviour. Its not the SimplePrincipal.equals/hashCode that is breaking these constraints. Symmetry and transitivity exist for any Principal implementation relying on the Principal.getName() alone. Any other implementation introducing additional information, such as the KerberosPrincipal, is separating itself into a new category. There is nothing our implementation can do to change this. You would have to create a Map with an ordered collection like TreeMap(Comparator<? super Principal> c) with a Comparator implementation that uses the least common denominator Principal.getName. What is the context in which this is a problem? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4077540#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...