Package 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`, `AmqpItemReader`, `AvroItemReader`, `FlatFileItemReader`, `HibernateCursorItemReader`, `HibernatePagingItemReader`, `ItemReaderAdapter`, `IteratorItemReader`, `JdbcCursorItemReader`, `JdbcPagingItemReader`, `JmsItemReader`, `JpaCursorItemReader`, `JpaPagingItemReader`, `JsonItemReader`, `KafkaItemReader`, `LdifReader`, `ListItemReader`, `MappingLdifReader`, `MongoItemReader`, `MultiResourceItemReader`, `Neo4jItemReader`, `RepositoryItemReader`, `ResourcesItemReader`, `SingleItemPeekableItemReader`, `StaxEventItemReader`, `StoredProcedureItemReader`, `SynchronizedItemStreamReader`

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, Mahmoud Ben Hassine

- ## Method Summary

  Modifier and Type
  Method
  Description
  `T`
  `read()`
  Reads a piece of input data and advance to the next one.

- ## Method Details

  - ### read

    @Nullable T read() throws 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 or `null` if the data source is exhausted
    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.
      `Exception` - if an there is a non-specific error.