RFR JDK-8139414: java.util.Scanner hasNext() returns true, next() throws NoSuchElementException

[Xueming Shen]

Hi,

Please help review the change for

JDK-8139414: java.util.Scanner hasNext() returns true, next() throws NoSuchElementException
JDK-8072582: Scanner delimits incorrectly when delimiter spans a buffer boundary

issue: https://bugs.openjdk.java.net/browse/JDK-8139414
        https://bugs.openjdk.java.net/browse/JDK-8072582
webrev: http://cr.openjdk.java.net/~sherman/8072582_8139414/webrev

In both cases the delimiter pattern is a kinda of "alternation" regex construct
which can "match" the existing characters at the end of the internal buffer as
delimiters, AND can extend to match more delimiters if more input is available.

In issue JDK-8139414, the hasNext() uses hasTokenInBuffer() to find the delimiters
"-;". It does not go beyond the boundary to check if there is more character, such
as "-" that can also be part of the delimiters). So hasNext() returns true with the
assumption that there is a token because there is/are more character after "-;".
But method getCompleteTokenInBuffer() (used by next() implementation), which
has the logic to check beyond the boundary even the delimiter pattern already
has a match. It matches "-;-" as the delimiters and then find no "next" (null) after
that.

Similar for issue 8072582. This time the getCompleteTokenInBuffer does not
use the "lookingAt() and beyond" logic for the second delimiters, which triggers
problem when the delimiter pattern has different match result (beginning position)
for cases within boundary and beyond boundary.

The proposed fix here is to always check if there is more input when match
delimiters at the internal buffer boundary.

Thanks,
Sherman