Class CardinalityCheckingIterator

  • All Implemented Interfaces:, java.lang.AutoCloseable, SequenceIterator

    public final class CardinalityCheckingIterator
    extends java.lang.Object
    implements SequenceIterator
    CardinalityCheckingIterator returns the items in an underlying sequence unchanged, but checks that the number of items conforms to the required cardinality. Because cardinality checks are required to take place even if the consumer of the sequence does not require all the items, we read the first two items at initialization time. This is sufficient to perform the checks; after that we can simply return the items from the base sequence.
    • Constructor Summary

      Constructor Description
      CardinalityCheckingIterator​(SequenceIterator base, int requiredCardinality, java.util.function.Supplier<RoleDiagnostic> roleSupplier, Location locator)
      Construct an CardinalityCheckingIterator that will return the same items as the base sequence, checking how many there are
    • Method Summary

      All Methods Instance Methods Concrete Methods 
      Modifier and Type Method Description
      void close()
      Close the iterator.
      Item next()
      Get the next item in the sequence.
      • Methods inherited from class java.lang.Object

        clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
    • Constructor Detail

      • CardinalityCheckingIterator

        public CardinalityCheckingIterator​(SequenceIterator base,
                                           int requiredCardinality,
                                           java.util.function.Supplier<RoleDiagnostic> roleSupplier,
                                           Location locator)
                                    throws XPathException
        Construct an CardinalityCheckingIterator that will return the same items as the base sequence, checking how many there are
        base - the base iterator
        requiredCardinality - the required Cardinality
        roleSupplier - information for use if a failure occurs
        locator - the location in the source stylesheet or query
        XPathException - if a failure is detected
    • Method Detail

      • next

        public Item next()
        Description copied from interface: SequenceIterator
        Get the next item in the sequence. This method changes the state of the iterator.
        Specified by:
        next in interface SequenceIterator
        the next item, or null if there are no more items. Once a call on next() has returned null, no further calls should be made. The preferred action for an iterator if subsequent calls on next() are made is to return null again, and all implementations within Saxon follow this rule.
      • close

        public void close()
        Description copied from interface: SequenceIterator
        Close the iterator. This indicates to the supplier of the data that the client does not require any more items to be delivered by the iterator. This may enable the supplier to release resources. After calling close(), no further calls on the iterator should be made; if further calls are made, the effect of such calls is undefined.

        For example, the iterator returned by the unparsed-text-lines() function has a close() method that causes the underlying input stream to be closed, whether or not the file has been read to completion.

        Closing an iterator is important when the data is being "pushed" in another thread. Closing the iterator terminates that thread and means that it needs to do no additional work. Indeed, failing to close the iterator may cause the push thread to hang waiting for the buffer to be emptied.

        Closing an iterator is not necessary if the iterator is read to completion: if a call on returns null, the iterator will be closed automatically. An explicit call on SequenceIterator.close() is needed only when iteration is abandoned prematurely.

        It is not possible to guarantee that an iterator that is not read to completion or will be closed. For example, if a lazy-evaluated variable $var is passed to a user-written function, the function may access $var[1] only; we have no way of knowing whether further items will be read. For this reason, any SequenceIterator that holds resources which need to be closed should use the Cleaner mechanism. The Configuration holds a Cleaner, and resources held by a SequenceIterator should be registered with the Cleaner; if the SequenceIterator is then garbage-collected without being closed, the Cleaner will ensure that the underlying resources are closed. (An example of a SequenceIterator that uses this mechanism is the UnparsedTextIterator).

        Specified by:
        close in interface java.lang.AutoCloseable
        Specified by:
        close in interface
        Specified by:
        close in interface SequenceIterator