XOM API for Processing XML with Java

[Wolfgang Hoschek <wolfgang.hoschek AT mac.com>]

> Likewise, the various equals() methods require that all subclasses  
> of XOM
> classes use identity (==) as the meaning of equality.  This means  
> that no
> subclass can function as a value class, because in value classes  
> (String
> is a familiar example), equality is defined recursively as part-by- 
> part
> equality rather than mere identity.  This is an unnecessary  
> restriction
> on the freedom of application developers.  If there are parts of XOM
> that depend on this definition of the equals() method, they should be
> rewritten to use == directly.
>
> I therefore urge that these methods be made non-final.  JLS 13.4.15  
> says
> that this change does not break binary compatibility, so it need  
> not wait
> for a new full release of XOM.

If Node.equals() would reimplemented to always throw an exception it  
would also be binary compatible, but nonetheless blow up all existing  
codes. Sometimes semantic contracts are more important than syntactic  
ones.

> For toString(), this is a mere stroke of
> the keyboard: for equals() and hashCode(), it may take a certain  
> amount
> of inspection, especially since hash collection classes use equals()
> implicitly.

In the absence of a good general purpose alternative, it's a  
widespread notion in XML that Node equality means Node identity (e.g.  
XPath, XSLT, XQuery).

For example, I have code that assumes these (final) XOM semantics,  
putting nodes into hashmaps and so forth. So changing the contract  
and suddently having other notions of equals() and hashCode() pop up  
would break existing codes. This would not be compatible.

Wolfgang.