<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I'm currently evaluating the alpha of JDOM2. Most of the problems
I've found with JDOM and Java 6 have been fixed in a utility class I
have called JDOMUtil. A good deal of the methods in there are
handling generic types, <br>
<br>
As for the question below, I don't often have the use case of for()
iterating over, element.getContent(), but I do often iterate over
the following:<br>
element.getChildren()<br>
element.getChildren(name)<br>
element.getChildren().isEmpty() as a surrogate for
element.hasChildren() <br>
<br>
You could have Element.getContent() return a List implementation of
your own, and make the Iterable.iterate() method in it (which is
what for() calls) be efficient. That might also make
element.getChildren.hasNext be efficient, or you could implement
isEmpty directly.<br>
<br>
For JDOMUtil, I often use these:<br>
JDOMUtil.selectElementChildren(element, xpath)<br>
JDOMUtil.selectElement(element, xpath)<br>
JDOMUtil.selectAttribute(element, xpath)<br>
JDOMUtil.ref(Element element, String xpath, String defaultValue)<br>
<br>
The JDOMUtil.ref(Element element, String xpath, String defaultValue)
method returns either the leaf-node value of the XPath expression,
or the defaultValue if the nodeset is empty.<br>
<br>
I've also wrapped every one of the JDOMUtil XPath calls with
something that throws a RuntimeException wrapper for JDOMException,
and I let pass JDOMException and IOException only on serialization
and parsing utilities. I believe that checked exceptions for XPath
errors are a detraction from the simplicity of JDOM. XPath
exceptions are always internal programming errors, and it is the
rare case where they can be corrected at the point of invocation.
Parsing and IO exceptions can come from external system interaction
and can reasonably be expected to be correctable in point source
code. <br>
<br>
Leigh.<br>
<br>
On 01/02/2012 12:27 PM, Rolf wrote:
<blockquote cite="mid:4F02133C.5010704@tuis.net" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="MS Exchange Server version
6.5.7036.0">
<title>[jdom-interest] JDOM and memory</title>
<!-- Converted from text/plain format -->
<p><font size="2">Hi all.</font>
</p>
<p><font size="2">Memory optimization has never been a top
priority for JDOM. At the same </font>
<br>
<font size="2">time, for what it does, JDOM is not a 'terrible'
memory user. Still, I </font>
<br>
<font size="2">have done some analysis, and, I believe I can
trim about a quarter to a </font>
<br>
<font size="2">half of 'JDOM Overhead' memory usage by making
two 'simple' changes....</font>
</p>
<p><font size="2">The first is to merge the ContentList class in
to the Element class (and </font>
<br>
<font size="2">also in to Document). This will reduce the number
of Java objects by </font>
<br>
<font size="2">about half, and that will save about 32 bytes per
Element at a minimum </font>
<br>
<font size="2">in a 64-bit JRE. Additionally, by
lazy-initialization of the Content </font>
<br>
<font size="2">array, we can save memory on otherwise 'empty'
Elements.</font>
</p>
<p><font size="2">This can be done by extending the Element (and
perhaps Document) class </font>
<br>
<font size="2">to extend 'List'. It can all be done in a
'backward compatible' way, but </font>
<br>
<font size="2">also leads to some interesting possibilities,
like:</font>
</p>
<p><font size="2"> for (Content c : element) {</font>
<br>
<font size="2"> ... do something</font>
<br>
<font size="2"> }</font>
</p>
<p><font size="2">(for backward compatibility,
Element.getContent() will return 'this').</font>
</p>
<br>
<p><font size="2">The second change is to make the AttributeList
instance in Element a </font>
<br>
<font size="2">lazy-initialization. This would save memory on
all Elements that have no </font>
<br>
<font size="2">attributes, but would have an impact for people
who sub-class the </font>
<br>
<font size="2">Element class and may expect the attributes field
to be non-null.</font>
</p>
<br>
<p><font size="2">I am trying to get a feel for how important this
sort of optimization </font>
<br>
<font size="2">may be. If there is interest then I will make
some changes, and test the </font>
<br>
<font size="2">impact. I may make a separate branch in github to
test it out....</font>
</p>
<p><font size="2">If the above changes are unrealistic then I
don't think it makes sense </font>
<br>
<font size="2">to even try....</font>
</p>
<p><font size="2">Rolf</font>
<br>
<font size="2">_______________________________________________</font>
<br>
<font size="2">To control your jdom-interest membership:</font>
<br>
<font size="2"><a moz-do-not-send="true"
href="http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com">http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com</a></font>
</p>
</blockquote>
<br>
</body>
</html>