No subject

Fri Aug 6 17:04:17 PDT 2004

using Text objects which contain a String rather than using String objects
directly. I found bigger performance gains using lazy construction to avoid
List creation (since they are much bigger, more complex, composite objects).
Also take a look at Michael Kay's "tinytree" implementation in SAXON for
some neat ideas on boosting performance.

So in the end I settled for a polymorphic XML tree API instead.

> A more general question is, when would this interface be useful? In
> terms, it seems to me that an interface is only useful if there are times
> (1) you can do useful work just by calling methods on that interface, w/o
> having to cast, and

I find this really useful. If your Node interface supports XPath expressions
one day, then you might too. I find I often don't need to cast to different
subtypes, Attribute, Element, Namespace, Text or whatever. I find myself
traversing trees using XPath.

    Node foo = document.getRootElement();
    Node bar = foo.selectSingleNode( "/a/b/c" );
    String name = bar.valueOf( "../d/@name ");

> (2) you don't care what type of object you're dealing with.
> Otherwise, your interface is no better than just using Object.

This depends on how useful your Node interface is I think. If Node is useful
enough then its better than object.

e.g. here's some fairly efficient tree traversal code based purely on Node
(and a Branch which could be an Element or a Document).

    for ( int i = 0; size < branch.nodeCount(); i < size; i++ ) {
        Node node = branch.node( i );
        switch ( node.getType() ) {
            case Node.ELEMENT_NODE:
            case Node.TEXT_NODE:

> For example,
> List fulfills these requirements (you usually don't care if it's an
> or a LinkedList).

Agreed - though List is a very useful interface :-)

> For graphical components, you often do care about the type,
> but during painting (for example), you don't.
> I theorize that you *always* care about the type of an XML object you're
> working with. In any real world example, you *never* want to treat an
> the same as an Attribute or Comment or ProcessingInstruction. They are
> used for completely different things. Of course, this in and of itself
> mean we shouldn't use this interface - just because I can't think of an
> example, doesn't mean that someone out there doesn't have a good reason
> this. But, I think that there would be a number of ugly things we'd have
to do
> to the JDOM API to work around the above problems (especially the String
> problem), so I think we'd really have to believe that this has substantial
> real-world uses before we do it, and not just hope that it does.

Agreed. I think the String issue is probably the most thorny issue that may
inhibit any kind of Node interface or polymorphism in JDOM.


Do You Yahoo!?
Get your free address at

More information about the jdom-interest mailing list