Bug 4276 - ItemReader and ItemWriter interface requires unnecessary methods
ItemReader and ItemWriter interface requires unnecessary methods
Status: CLOSED FIXED
Product: jbatch
Classification: Unclassified
Component: source
1
All All
: P5 critical
: ---
Assigned To: cvignola
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-09 20:29 UTC by mminella
Modified: 2013-01-16 15:18 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mminella 2012-11-09 20:29:18 UTC
The @Open, @Close and @Checkpoint annotations are not required when using annotations yet when we use interfaces, all of the methods are required.  This interface should be broken up into multiple interfaces to correctly reflect which methods are required.
Comment 1 ScottKurz 2012-11-09 20:46:02 UTC
Instead of adding more interfaces to the API and complicating the inheritance tree, this could also be dealt with by simply specifying that an implementation has to accept a checkpointInfo() method returning 'null'.

In this way a reader/writer developer could either choose to no-op the interface methods, or to use the annotations (with optional ones of course being optional).
Comment 2 cvignola 2012-11-17 16:55:27 UTC
I agree with Scott.  I think the inheritance complexity outweighs the value.  We could either follow Scott's suggestion (documentation) or provide an abstract class that provides no-op implementatations of the optional methods.  

As an exercise,  I thought about using multiple interfaces, and in order to achieve equivalence with the permutations possible using the annotations, we'd have to have the following (stylized) interfaces:

1. interface ItemReader {
public Item readItem();
}

2. interface OpenableItemReader extends ItemReader {
public void open();
}

3. interface ClosableItemReader extends ItemReader {
public void close();
}

4. interface CheckpointableItemReader extends ItemReader {
public CheckpointInfo getCheckpointInfo();
}

Possible concrete classes:

class MyOpenableReader implements OpenableItemReader { ... }
class MyClosableReader implements ClosableItemReader { ... }
class MyCheckpointableReader implements CheckpointableItemReader { ... }
class MyOpenableClosableReader implements OpenableItemReader,ClosableItemReader { ... }
class MyOpenableCheckpointableReader implements OpenableItemReader,CheckpointableItemReader { ... }
class MyClosableCheckpointableReader implements ClosableItemReader,CheckpointableItemReader { ... }
and finally, fully tricked out ...
class MyOpenableClosableCheckpointableReader implements OpenableItemReader,ClosableItemReader,CheckpointableItemReader { ... }

I think interface decomposition is most useful
when the resultant interfaces represent discrete entities that occur naturally
in the problem domain.  Maybe it's just the way I'm looking at it, but I am
not seeing that in this case.
Comment 3 cvignola 2012-12-06 16:54:01 UTC
We will use the abstract class approach to separate required from optional methods.