Add test for Bug 5875

[scottkurz]

Some specific things to test:

• writeItems w/ empty buffer
• item-count is on processed items, not read items

[scottkurz]

Apologize for making public my scratch notes to myself...

1. read at least one item in chunk a) processor as "filter", writer never gets a 'null', at least one item processed b) all are filtered by processor, test that writer gets called with empty list
2. on "zero-item" chunk, a) processor isn't called, b) writer isn't called

  Some tck tests seem to expect ItemWriter not called:       ChunkTests.testChunkDefaultItemCount    ChunkTests.testChunkNoProcessorDefined

[scottkurz]

For reference:

• "zero-item chunk" is one in which, immediately after a checkpoint, the reader's first readItem returns null
• "Filtered" means readItem returned non-null but processItem returned "null"

Note this could expose some back compatibility issues in the RI and/or TCK, which is a whole other set of considerations, but let's move forward.

[scottae22]

Regarding "item-count is on processed items, not read items " If a read item is null, don't increment the item-count only commit after item-count# of non-null items read in how to test: make a reader that generates 25 items: use skipReader, arraysize=25, readrecord.fail="" pass to a processor that filters out 5 of them: make new one based on dosomethingarrayitemprocessorimpl writer should keep count of times called: make new one based on dosomethingitemwriterimpl. set exit status each write so that value can be retrieved. set item-count to 5 5 items won't be processed, so total items is 20 check that the writer is only called 4 times. if null were counted, it would have instead be called five.

Test process seems to be good. unfortunately, the RI seems to fail this test. the chunk sizes are 4, and five writes are being done. I'll need to look at the controller to find out how this was implemented and if it needs to change chunkStepSonctrollerImpl line 262: item is processed. in this case, isFiltered() may be set to True. if true, item is not added to chunk to write. regardless of boolean, line 289: isReadyToCheckPoint() for the item checkpoint algorithm we use, the first thing it does it increment number of items read. (variable is itemsRead, not itemsProcessed) It then compares that number to the item-count. So, the issue is, that number increments regardless of how the item was processed Would it make sense to not checkpoint on a null item? i'm going to try that on the whole TCK and see what happens

So, the RI needs to change, since the controller is changing. but, the RI has tests too, and they fail with the changes. 3 of the tests also keep count of number of commits. When we only commit on non-nulls, we miss many of the expected count.

^^The above is notes I made for myself while working on this issue; hopefully they make sense to whoever works on it next. I stopped because I was unclear on what the correct behavior should be and how much of the RI/tests needed to be changed. scottae22/standards.jsr352.tck/issue22count and scottae22/standards.jsr352.jbatch/nullCheckpointBehaviorChange have the changed files mentioned here.