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

Xueming Shen xueming.shen at oracle.com
Thu Sep 10 21:32:39 UTC 2015


On 09/10/2015 01:55 PM, Paul Sandoz wrote:
> On 10 Sep 2015, at 22:22, Stuart Marks<stuart.marks at oracle.com>  wrote:
>>>> It'd be better to initialize expectedCount to modCount in constrocutor?
>> That's how I had it initially, but at Paul Sandoz' suggestion I delayed the initialization to the first call to tryAdvance().
> Yes, it’s preferable to have a "late-binding” Spliterator, as is the case for Matcher and collections.
>
> The “best-effort” implementation is more than sufficient given the extremely low probability of non-detection.

Well, you only need to have a separate boolean field for the "first invocation of tryAdvance()"
instead of utilizing the modCount for two purposes. But it's true there is no guarantee nothing
is going to happen between the modCount check and  hasNext()... I leave it to the expert:-)

> Paul.
>
>>   This allows the Scanner's state to be modified after stream creation but before stream pipeline execution. This is the way that Paul's stream code in Matcher works. I'm not sure how important this is. Having Scanner be gratuitously different from Matcher seems like it would be irritating though.
>>
>




More information about the core-libs-dev mailing list