Hi, John. Sorry for the long delay.
The original authors of JXPath are long gone, but from what I can
reconstruct the intent of nested JXPathContexts is only to unify treatment
of things like variables, namespaces, and at a guess, functions. AFAICT
your test case appears to have overcomplicated
Pointer is an interface that is considered part of the public API. Very
possibly the intent could have been more elegantly expressed by using the
NodePointer API, but this *would* be a case of relying on an implementation
detail, as NodePointer is the Pointer implementation used by
Yep, that makes a certain kind of sense, though I guess I wouldn't
exactly call it intuitive. I can see how creating a new context each
time could be a bad idea (and very inefficient, I suspect)...though it
seems (to a newbie anyway) that the pointers are an implementation
detail that leak out
On 04/25/2014 12:42 PM, Matt Benson wrote:
Pointer is an interface that is considered part of the public API.
Very possibly the intent could have been more elegantly expressed by
using the NodePointer API, but this *would* be a case of relying on an
implementation detail, as NodePointer is
Hi all,
I'm trying to learn how to use JXPath with DOM in order to speed up some
code that uses a lot of xpath. I've seen blog posts suggesting it's
about twice as fast as JAXP's XPath processor...
The problem I'm running into is when I construct a JXPathContext around
a node down in the
