Details
Improvement
Open
Major
Description
issue migrated from sourceforge
Hello-
why are you using == inside the default impl of
FollowingSiblingAxisIterator? I would suggest changing
to .equals() ?
line of code is:
<pre>
else if ( eachChild == this.contextNode )
</pre>
My object model does not guarantee == for equality. I
have custom impl as a workaround so this is not a big
deal.
Thanks
-David
(the answer is that DOM doesnt support equals. I'm not just closing this because it may be worthwhile to add a node equality test to the navigator interface - brian)
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.