[
https://issues.apache.org/jira/browse/JXPATH-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840858#action_12840858
]
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 you?
> NodeIterator usage in AttributeContext
> --------------------------------------
>
> Key: JXPATH-134
> URL: https://issues.apache.org/jira/browse/JXPATH-134
> 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.
