[jdom-interest] DocType equals()-hashCode() contract violation

Elliotte Rusty Harold elharo at metalab.unc.edu
Wed Apr 17 09:23:07 PDT 2002

The DocType class uses a custom equals() method but does not use a 
custom hashCode() method; i.e.

    public final boolean equals(Object ob) {
        if (ob instanceof DocType) {
            DocType dt = (DocType) ob;
            return (stringEquals(dt.elementName, elementName) &&
                    stringEquals(dt.publicID, publicID) &&
                    stringEquals(dt.systemID, systemID));
        return false;

    public final int hashCode() {
        return super.hashCode();

Thus two equal DocType objects may have different hash codes. We need to 
fix one of these methods. Either equals() needs to return super.equals() 
or we need to calculate the hasCode based on the elementName, publicid, 
and systemID. I'm not sure which one to patch. My initial reation is to 
fix hashCode(). Thoughts? Either way this change should not break 
existing code.

Issue 2: Should we consider the internal DTD subset when comparing two 
DocTypes for equality (and when calculating the hash code)? My suspicion 
is we should. Two DocTypes with the same root element name can be very 
different if the internal DTD subset is different. The again they may be 
effectively the same modulo white space and other insignificances. Is it 
more important to ensure that two inequal DTDs are not reported as equal 
or that two equal DTDs are not reported as inequal?

| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
|           The XML Bible, 2nd Edition (IDG Books, 2001)             |
|             http://www.cafeconleche.org/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
|  Read Cafe au Lait for Java News:   http://www.cafeaulait.org/     | 
|  Read Cafe con Leche for XML News:  http://www.cafeconleche.org/   |

More information about the jdom-interest mailing list