org.springframework.batch.item

## Interface ItemReader<T>

- All Known Subinterfaces:
    ItemStreamReader<T>, PeekableItemReader<T>, ResourceAwareItemReaderItemStream<T>
  All Known Implementing Classes:
    AbstractCursorItemReader, AbstractItemCountingItemStreamItemReader, AbstractItemStreamItemReader, AbstractPaginatedDataItemReader, AbstractPagingItemReader, AggregateItemReader, AmqpItemReader, ExceptionThrowingItemReaderProxy, FlatFileItemReader, GeneratingTradeItemReader, HibernateCursorItemReader, HibernatePagingItemReader, IbatisPagingItemReader, InfiniteLoopReader, ItemReaderAdapter, ItemReaderAdapter, IteratorItemReader, JdbcCursorItemReader, JdbcPagingItemReader, JmsItemReader, JpaPagingItemReader, LdifReader, ListItemReader, MappingLdifReader, MongoItemReader, MultiResourceItemReader, Neo4jItemReader, OrderItemReader, RepositoryItemReader, ResourcesItemReader, SingleItemPeekableItemReader, StagingItemReader, StaxEventItemReader, StoredProcedureItemReader

      public interface ItemReader<T>

  Strategy interface for providing the data.
  Implementations are expected to be stateful and will be called multiple times for each batch, with each call to `read()` returning a different value and finally returning `null` when all input data is exhausted.
  Implementations need not be thread-safe and clients of a `ItemReader` need to be aware that this is the case.
  A richer interface (e.g. with a look ahead or peek) is not feasible because we need to support transactions in an asynchronous batch.
  Since:
    1.0
  Author:
    Rob Harrop, Dave Syer, Lucas Ward

- - ### Method Summary

    All Methods Instance Methods Abstract Methods
    Modifier and Type | Method and Description
    --- | ---
    `T` | `read()` Reads a piece of input data and advance to the next one.

- - ### Method Detail

    - #### read

          T read()
          throws java.lang.Exception,
                 UnexpectedInputException,
                 ParseException,
                 NonTransientResourceException

      Reads a piece of input data and advance to the next one. Implementations must return `null` at the end of the input data set. In a transactional setting, caller might get the same item twice from successive calls (or otherwise), if the first call was in a transaction that rolled back.
      Returns:
        T the item to be processed
      Throws:
        `ParseException` - if there is a problem parsing the current record (but the next one may still be valid)
        `NonTransientResourceException` - if there is a fatal exception in the underlying resource. After throwing this exception implementations should endeavour to return null from subsequent calls to read.
        `UnexpectedInputException` - if there is an uncategorised problem with the input data. Assume potentially transient, so subsequent calls to read might succeed.
        `java.lang.Exception` - if an there is a non-specific error.