XOM API for Processing XML with Java

[John Cowan <cowan AT ccil.org>]

First, I want to make clear that I agree with the general principle
of making classes and methods final unless there is a clear reason for
allowing subclasses or overriding respectively.  I then want to argue
for a general exception to this case, namely the non-final public methods
inherited from Object class: equals(), hashCode(), and toString().

There are two sets of expectations for these methods: that they can
be called by a client on any object, and that the designer of a new
class can define them in ways suitable for the class.  For example, it
is common for classes in Java to redefine the equals() and hashCode()
methods so as to implement a class-specific notion of equality.
(Defining one without the other is a Bad Thing, since objects of the
same class which are equal also must have identical hash codes.)

XOM violates this second expectation in its declarations of these method.
Consider the toString() method.  The JavaDoc for Object class recommends
that toString() returns a string which is "a concise but informative
representation which is easy to read."  Now an object may be made a
subclass of of Element in order to give it a natural representation
in XML.  This does not mean, however, that the most informative
representation is one that is suitable for a generic XML element.
If the class is an application class, a suitable representation ought
to be relevant to the application.

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.  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.

-- 
John Cowan   <cowan AT ccil.org>   http://www.ccil.org/~cowan
One time I called in to the central system and started working on a big
thick 'sed' and 'awk' heavy duty data bashing script.  One of the geologists
came by, looked over my shoulder and said 'Oh, that happens to me too.
Try hanging up and phoning in again.'  --Beverly Erlebacher