commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Benson (JIRA)" <>
Subject [jira] Commented: (JXPATH-134) NodeIterator usage in AttributeContext
Date Wed, 03 Mar 2010 20:26:27 GMT


Matt Benson commented on JXPATH-134:

Firstly, JXPath is not in such a state as to permit any far-reaching changes to its API, and
particularly not the API of its reference implementation.  In theory, if you don't like the
RI API, you are fully free to rewrite your own JXPath implementation.  That said, I would
not be averse to enhancing the javadoc of {{NodeIterator}}.  I also still don't follow where
you're going with the last two lines of the above comment.  What is the origin of this report,
and what precise problem did the API and/or its documentation, or lack thereof, present for

> NodeIterator usage in AttributeContext
> --------------------------------------
>                 Key: JXPATH-134
>                 URL:
>             Project: Commons JXPath
>          Issue Type: Bug
>    Affects Versions: 1.3
>         Environment: JDK 1.5.0_12
>            Reporter: Vladimir Orlov
> There is the following piece of code in AttributeContext class, nextNode() method:
>         if (!iterator.setPosition(iterator.getPosition() + 1)) {
>             return false;
>         }
> It implies that the following precondition is satisfied in the NodeIterator implementation:
in its initial state NodeIterator implementation has the position set in 0 when the first
position index is actually 1. At the same time NodeIterator interface implies that the client
code should call the setPosition() method of the NodeIterator first and only after that it
can call the getPosition()  or getNodePointer(). There is no any information about such a
strange condition to satisfy for the NodeIterator implementation in the Javadoc.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message