DO NOT REPLY [Bug 8783] New: - QName.hashCode() inconsistent with QName.equals(Object)

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8783>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8783

QName.hashCode() inconsistent with QName.equals(Object)

           Summary: QName.hashCode() inconsistent with QName.equals(Object)
           Product: XalanJ2
           Version: CurrentCVS
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: org.apache.xml.utils
        AssignedTo: xalan-dev@xml.apache.org
        ReportedBy: achille@us.ibm.com


Part of the general contract of hashCode() method is that "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."
Unfortunately, this is not true for org.apache.xml.utils.QName. In fact, 
QName.hashCode() is a function of its prefix, its namespace and its local name 
whereas QName.equals(Object) is just a function of its namespace and local 
name. This means that two QNames which differ only by their prefixes would be 
considered equal but their hashCode values would be different( e.g. new QName
("http://examples.org","a", "example") and new QName
("http://examples.org","b", "example").
This inconsistency could lead to serious bugs if QNames are used as keys of 
hash maps.