use of == not equals

I just got bit by this. In the XOM internal navigator (not the one that ships with Jaxen, the one bundled with XOM) XPath text nodes are constructed on the fly and are not always == but are equals(). Therefore I had a bug in using this axis.

I switched FollwoingSibling (and NodeComparator) over to using equals() instead and the problem was fixed, and nothing else broke.

Remember, DOM doesn't support equals(); but in Java a class that doesn't have an equals() method inherits one from the java.lang.Object class which just uses == to compare. Thus using equals() here is likely more correct. Calling equals() basically means we've used equals() for classes that cared enough to override it, and == for every other class.

This may be important for other, stranger object models that have more sophisticated storage models; using databases or tables, for instance. In these cases, there may be fewer objects than nodes, and == may also not work.

So far I can't think of any cases where == would work and equals() would not work, barring deliberately perverse things like an equals() method that always returns false.

Theres a couple of scenarios:

• == is true, .equals() false. This would be perverse, as you say.
• .equals() is true, == is false, and the two nodes "are the same". This can happen with pooled entities and the like, and would be a problem for jaxen now.
• .equals() is true, == is false, and the two nodes are different. This can happen when the OM just compares QNames.

Thats why I think the equality test should be on the navigator. But breaking API changes belong in 2.0.