[jdom-interest] Streaming JDOM

Tatu Saloranta cowtowncoder at yahoo.com
Mon Jul 24 10:27:34 PDT 2006

--- Gregor Zeitlinger <gregor at zeitlinger.de> wrote:

> On 7/18/06, Tatu Saloranta <cowtowncoder at yahoo.com>
> wrote:
> > This is a reasonable direction to take. I wrote
> > StaxMate (http://woodstox.codehaus.org/StaxMate),
> > which does use similar api.
> Yes, it is indeed similar, but do you have examples?
> I could not find getAttribute(name)

Yes, 0.6 had a few omissions. ;-)

I really need to get 1.0 released -- the version in
subversion repository is significantly different from
one downloadable from the page (I had forgotten how
outdated 0.6 was... sorry!)

Anyway, since StaxMate is not really directly related
to JDom, we can take discussion off the list.
I'll also try to find time to post some simple example
on my blog (at
as soon as I get Woodstox 3.0-final out, I should have
more time for related projects.

> I tried to make my API as similar as possible to
> JDOM, because
> - I think JDOM is easy to use
> - the API should be easy to learn for JDOM users
> - I was hoping it might be included in JDOM
> Regarding the last issue:
> I am wondering if the JDOM implementors do not want
> to have a
> streaming API or if this is just the wrong mailing
> list to ask this
> question.
> Can anybody enlighten me?

I'm not a JDOM implementor per se, but reasons I can
think of
for not getting many responses are:
(and btw, I think this mailing list is just right for

* JDom is a rather mature tree model, and most users
  are either content with it, or moved to
  more suitable alternatives
* Being a tree model implementation, focusing on
  may be considered out of scope.
* Implementing any truly streaming mode of operation
  maintains convenience of a tree model is quite
  thing to do.

But regarding "streaming in JDOM", the main question
to me is
what exactly are you trying to achieve?
Efficiency/speed of streaming approach, or something
that is
"just faster than the eager loading"?
There may be other goals too, but from these two,
you'll get
following obvious implementation choices:

(a) Faking a real tree structure by allowing limited
  (one-way, forward-and-parents only, or such)
(b) Implementing what amounts to 'lazy instantiation',
  only build parts of the tree that one needs

Latter allows full convenience, but generally does not
either speed things up or really reduce memory usage.
In common
case, the whole tree still ends up being loaded. At
least that
seemed to be the conclusion of Xerces/DOM implementors
and users.
In former case, usage limitations are such that it's
whether it's much more convenient than using an
approach that
makes such limitations explicit (such as perhaps using
streaming interfaces). But it can be quite efficient.

-+ Tatu +-

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the jdom-interest mailing list