So if such an optimization was added there would be a way to by-pass it
as well? [This can't just be "if Xalan is not present" -- as Xalan is
present for other reasons.]
--
Jess Holle
Dmitri Plotnikov wrote:
Jess,
JXPath has always supported Xalan through JAXP DOM APIs. What you may have
seen in the source code of JXPath is some attempts to optimize JXPath when it
is used specifically in combination with Xalan. You would not be interested in
that optimization, because it would only be applied to static DOM and take
advantage of DTM.
Try using JXPath and let us know how it works out.
- Dmitri
Jess Holle <[EMAIL PROTECTED]> wrote:
P.S. Also, I must admit this message is somewhat of a test. If no one
responds, then I can assume the JXPath community is not active enough to
be worth considering over sticking with an old version of Xalan for the
forseeable future.
Jess Holle wrote:
I am using Xalan 2.1.0 for XPath coverage presently -- behind a skinny
wrapper API so we can change implementations fairly painlessly.
I'd like to use something more recent and was looking at JXPath, but I
note that the sources contain "TO_DO" comments about using Xalan as
the backing XPath implementation -- for the DOM case presumably.
Is this the plan? If not, what is?
If this is the plan, then there is no reason for me to switch from
Xalan to JXPath -- as I only care about XPath usage against DOMs (not
JDOM, other beans, etc).
You may ask why I'm on such an old Xalan or why I'm looking for
something other than Xalan -- which are good questions...
Essentially, recent versions of Xalan are missing the boat on some
important XPath use cases. Xalan 2.1.0 is the last version of Xalan
which does not have immense performance penalties for my use cases.
Specifically, my use case is:
1. Parse/compile XPath expressions.
2. Use these expressions against many different DOMs.
* I /rarely /use a given XPath against the same DOM (without
intervening changes) twice.
o I /often /use a given XPath against many, many
different DOMs.
* I /even more rarely /know that when I use an XPath on a DOM
it will not be changing prior to it being used again.
* I /often /need to use XPath to retrieve a list of DOM nodes
to be edited or deleted -- followed by edits directly via
DOM APIs and more use of other XPaths ad nauseum (e.g. based
on GUI picks).
After Xalan 2.1.0, the XPath portion of Xalan was optimized for the
antithesis of this use case, i.e. it builds a DTM (document table
model) for each DOM an XPath is used against -- which is a tremendous
waste of time and memory if the XPath is all but certainly not going
to be used against the given DOM (without intervening changes) more
than once. I found cases of 500% performance improvement by moving
back from more recent Xalan versions to 2.1.0 for these use cases!
The Xalan team knows about this issue, but despite the fact that this
directly affects the XPath API exposed in Java 1.5 this issue seems
unimportant/uninteresting to them as compared to optimizing for the
XSLT use case -- where the DTM approach makes sense since the DTM is
formed once and acted upon by many XPaths many times.
Some time ago I looked at both JXPath and Jaxen as possible
replacements for Xalan 2.1.0. Unfortunately, both of these XPath
libraries had major issues with evaluating some rather simple XPath
expressions at the time -- and I need good fidelity to the XPath
standard (at least as good as Xalan 2.1.0). I believe Jaxen is at the
same version now as it was when I last tested it, but JXPath has had
an update or two since then -- so I was going to try again until I saw
the aforementioned "TO_DO" in the source code. If JXPath is not going
to be a long-term contender for the my use cases, then I just have to
continue using Xalan 2.1.0 (which I've move to another package using
Ant -- similar to what Sun has done in Java 1.5 -- so as not to
conflict with any other Xalan versions).
So all that said, I'd appreciate any feedback as to:
* the intended direction of JXPath,
* the level of commitment to the XPath standard, and
* the level of commitment to supporting the non-XSLT DOM use case
outlined above.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
