[jdom-interest] Re: progressive parsing/minimizing memory footprint

[Cem Karan]

Thanks, I'll keep an eye out for both.  As it stands, I'm going to
continue using JDom and just make sure that the server has enough RAM to
handle everything.  

I do like the idea of being able to choose subtrees from those that are
available using XPath.  As a temporary stop gap, is it possible to
modify JDom to do a progressive parse?  My thought was this:  When you
build a Document, it in reality only creates the Document with PIs and
such, and the root Element.  Internally, all child Elements of the root
are null.  Only when you ask for a child using some specialized get
method is it filled out.  Again, the child's child Elements are null
until you ask for them.  If we make it so that the get method returns a
new Element rather returning (this) filled out with the appropriate
data, then all you have to do is let the Element go out of scope and it
will be garbage collected.

I'll admit that this will most likely be fairly slow with all the disk
access that would be necessary, and all the creation of new Elements. 
But it would reduce memory down to a bare minimum, which might be a
problem for others besides myself.

Cem Karan

Joseph Bowbeer wrote:
> 
> Cem.Karan at usa.alcatel.com writes:
> 
> > Is there a way to get all the benefits of JDOM
> > in a low memory footprint?
> 
> There's nothing ready-built available now.
> 
> If the ambitious JDO project ever bears fruit, then it should be possible to
> use JDO's enhancer to create a "persistence capable" JDOM Document.
> 
>  Java Data Objects (JDO)
>  http://java.sun.com/aboutJava/communityprocess/review/jsr012/
> 
> There was a lot of enthusiastic discussion about event-based processing last
> November.  The idea was to create a streaming SAXBuilder that would generate
> a stream of JDOM Elements selected by an XPath expression.
> 
> http://lists.denveronline.net/lists/jdom-interest/2001-April/005485.html