RFR(m) 2: 8072722: add stream support to Scanner

[Paul Sandoz]

On 9 Sep 2015, at 02:53, Stuart Marks <stuart.marks at 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
>