XOM API for Processing XML with Java

[Bill de hÓra <bill AT dehora.net>]

Elliotte Rusty Harold wrote:

> On further reflection, I've figured out a relatively clean way to do 
> this. As well as comparing the class and package names, I have to 
> compare the hash codes.  I have to use the hashCode() because I need a 
> method in Object that's guaranteed to be available to both versions of 
> the Attribute.Type class.
>
> I just hope none of my students catch me doing this. Every semester I 
> take off lots of points on homework from students who implement equals 
> by comparing the results of either hahsCode() or toString() instead of 
> implementing the equals() method directly. :-)

Because equal hashCodes don't entail object equality, though all 
equal objects have equal hashCodes (a neccessary but not sufficient 
condition).

IMO this is one of the places where Java is plain broken; it's right 
up there with being able to assign a value to a String literal, 
Object[] weirdeness and the memery model. The only way I know to 
deal with this problem is a fall back to a value type check where 
instanceof chucks. This may seem inelegant and defeat the point of a 
enum, but is that more important that having bogus semantics for 
equals()? Becuase hashCode isn't correct. You can at least hide the 
fallback value field as private and use reflection to get a handle 
on it, but it sure makes for a weird looking equals(). Bizarrely, 
the DOM crowd probaly got this one right on accident for Java.

Bill de hÓra