Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


Converting a Java Object to an Item

  • One of my extension functions uses a custom implementation of SequenceIterator as an adapter wrapped around another program's iterator. Since SequenceIterator iterates over Item objects, I have to convert a Java Object to an Item in Java (i.e. I don't think I can use Saxon to do it for me - the class has to explicitly convert it). However, there doesn't seem to be an easy way to do this!

    Saxon, it seems can convert Value objects to Item objects, and Java Objects to Value objects. This resulted in the cumbersome code:

    public Item next() throws XPathException {
    // Get the next item in the sequence.
    if (results.hasNext()) {
    currentItem = Value.asItem(
    return currentItem;
    } else {
    return null;

    (Where results's class implements java.util.Iterator.) Is there a less hacky way of converting an arbitrary Java Object to an Item?

    P.S. The net.sf.saxon.value.Value class has a horribly horribly generic name! There was a namespace collision with the other program I was using, and I had to import it explicitly (i.e. without "net.sf.saxon.value.*"). net.sf.saxon.om.Item also has an odd name. These two function should be renamed, if possible.

    • Michael Kay
      Michael Kay

      No, I can't think of a simpler way to do it.

      I've thought for a while about making Value into an interface and having NodeInfo extend Value, so that every Item is a Value: this would better reflect the XPath data model. I'm a little reluctant because it would make it much harder work to write a new implementation of NodeInfo. This seems to be a case where delegation is appropriate (the class SingletonNode is used to wrap a NodeInfo as a Value), but this does mean some extra code is needed when you want to treat an Item as a Value.

      Note that not every value can be treated as an Item: a value is in general a sequence of items.

      The terms Item and Value are pretty fundamental in the XPath data model (just as sequence and node are) and I see no harm in using them as class names. Java package names exist in prder to resolve conflicting class names, and I see no value in duplicating this mechanism by including extra qualifiers within the local name of the class.

      Michael Kay