[jdom-interest] deffered-build document implementation (was [jdom-interest]
Cem.Karan at usa.alcatel.com
Wed Apr 18 05:12:30 PDT 2001
> > Is there any way to analyze large files without program
> > termination und
> > without command: "java -Xms<size> -Xmx<size> SomeClass"?
> > Any "deffered-build document implementation"?
> No, at least not yet. Since the default memory size is 16 mb (I think) it's
> pretty unlikely that a 13 mb document will ever fit in it though. We would
> have to be *very* clever :-)
I mentioned this before, but I'll mention it again as to how to modify
JDom for this to work. Rather than building the whole tree, only grab
the root element and everything associated with it at that level. When
the user asks for a child, s/he gets back both the child and an XPath
object that points to that child (or maybe these two can be invisibly
combined, I don't know, I'm just throwing out ideas at the moment) When
you ask for the child's child, the XPath object determines which child
to start from in the XML document. The rest proceeds as normal. At
each stage, you only need the current Element in order to go forward or
backwards because of the XPath object. That means that in our 16 Mb,
you could have the 13 Mb data file, and ONE Element pointer to get
around. Or, you can keep the file on disk and know that you will ALWAYS
use a fairly small and fixed amount of memory. I know that it wouldn't
be that fast; parsing out the whole file means that searching just means
scanning through the pointers rather than parsing each time, but on the
other hand, memory strapped applications, or applications that have
truly enormous XML files to work with will be able to use JDom.
All of that said, I will state a disclaimer. I'm a user of JDom, I
haven't poked around on its insides that much. I truly don't know how
much mucking around with the code would be required to do this. It just
seemed like the best way of doing things that I could think of.
More information about the jdom-interest