JDOM provides JDOMResult which can be fed into the transform API to directly
generate JDOM tree. I've never profiled the JDOMResult to see memory
implications of using it.
>If you start with a DOM rather than a JDOM, you should avoid at least some
>of the memory overhead. If you can start with a SAX stream you should avoid
>more.
This would be reasonable thing to do if the JDOMResult is using too
much of buffer allocations.
-----Original Message-----
From: Joseph Kesselman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 10:22 AM
To: [EMAIL PROTECTED]
Subject: Re: Memory Consumption
Xalan does not have native support for JDOM. To style from a JDOM the
document has to be recopied through SAX into our internal DTM model (or
from JDOM into a DOM which can then be wrappered by our DOM2DTM adapter
layer).
If you start with a DOM rather than a JDOM, you should avoid at least some
of the memory overhead. If you can start with a SAX stream you should avoid
more.
If/when we get XDM in place as our universal data-model API, someone may
write an XDM layer for JDOM and that ought to be at least semi-efficient.
(Comparable to running XDM over DOM, which should be much better than
running DTM over DOM). But don't hold your breath; XDM is still under
development and unstable (which is why I'm still pounding on a private
copy; it ain't ready for prime time), and JDOM support is just about dead
last on my own list of priorities (though I wouldn't object if someone else
tackled it).
______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
"The world changed profoundly and unpredictably the day Tim Berners Lee
got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
