[jdom-interest] streaming document output
jdom at tuis.net
Thu Apr 11 11:15:17 PDT 2013
OK, you have a long list of child Elements, and you generate them
on-the-fly during output. You also fudge the same in JDOM 1 by using
indexed access too. Now JDOM 2.x is not using the iterator....
... OK, I see the problem. I think the right fix would be for the
XMLOutputter to use the iterator (yes, they are faster in JDOM 2 than
1.x, but maybe not as fast as indexed access)....
As a side note, yes, XMLOutputter is final, by design. The bulk of the
logic is 'exported' to the interface XMLOutputProcessor, and there's a
'nearly' concrete implementation of that -
- read the comments. If a fix for the core JDOM code is not enough, you
will likely want to extend the AbstractXMLOutputProcessor and override
I wrote a little blurb on why I changed the XMLOutputter to be final
Let me inspect the code for where you believe the index-based lookups
are.... if you have a pointer for where I should start that will
help.... Ahh, it's in the Walker classes... that is a little bit
'hairy'. Let me play with it a little bit.
On 11/04/2013 1:29 PM, Patrick Dowler wrote:
> We have a few web services that send XML documents in the response.
> The documents can be large and when they are there is always one spot
> where there is an arbitrarily long list of child elements.
> With jdom1 we had implemented a subclass of Element for the element
> with the long list of child elements and then had the iterator over
> that list dynamically generate the children. Since the XMLOutputter
> used indexed access rather than the iterator, we also had to subclass
> it and override the list access. That works fine at the time.
> No we are porting to jdom2 and I see that the outputter still uses
> indexed access; that is a shame given all the comments in the code
> about how the iterator is generally better than having to call size()
> on the lists. It would be really nice and enable people to implement
> customisations if jdom2 used the iterators rather than the indexing
> throughout the codebase. Is that a lot of work?
> The further problem we have right now is that XMLOutputter is final so
> we can't trivially port our jdom1 code. Is implementing a custom
> XMLOutputProcessor the right place to do that? The change we'd be
> making is to change it to use iterators... is that something that
> should go into the core library?
> For XMLOutputProcessor, I am looking specifically at these methods:
> Is that the place to change to iterators?
More information about the jdom-interest