On 9 Sep 2015, at 02:53, Stuart Marks <stuart.ma...@oracle.com> wrote:
> I think the following covers all of the before, during, and after cases.
>
> << Scanning starts upon initiation of the terminal stream operation, using
> the current state of this scanner. Subsequent calls to any methods on this
> scanner other than {@link #close} and {@link #ioException} may return
> undefined results or may cause undefined effects on the returned stream. The
> returned stream's source {@code Spliterator} is <em>fail-fast</em> and will,
> on a best-effort basis, throw a {@link
> java.util.ConcurrentModificationException} if any such calls are detected
> during pipeline execution. >>
>
> The reset() method will reset the delimiter, locale, and radix, but it can't
> reset the position in the input, so the scanner effectively cannot be reused
> after any stream operation has been initiated.
>
> I'll add the following:
>
> << After stream execution completes, this scanner is left in an indeterminate
> state and cannot be reused. >>
>
Ah, shame, which strongly suggests advising that the stream/scanner should
always be closed afterwards, regardless of whether it contains a resource to be
released. Not sure we need to say anything, up to you.
> The closed behavior is separate from CME, so I'll add the following to the
> text that covers the closing behavior.
>
> << IllegalStateException is thrown if the scanner has been closed when this
> method is called, or if this scanner is closed during pipeline execution. >>
>
> All of the above apply to both the tokens() method and the main findAll()
> method.
>
>> You might need to double check FindSpliterator for the before and during
>> cases as i don’t think findPatternInBuffer checks if the scanner is closed,
>> i think it needs an ensureOpen call in tryAdvance.
>
> Good catch! I've added an ensureOpen() call here and I've also add tests to
> cover this case.
>
> Updated webrev:
>
> http://cr.openjdk.java.net/~smarks/reviews/8072722/webrev.3/
>
+1.
Paul.
> Updated specdiff:
>
> http://cr.openjdk.java.net/~smarks/reviews/8072722/specdiff.3/overview-summary.html
>
> s'marks
>
