No, it isn't. It is separated by comma or spaces(s), because that is what you wrote as your delimiter. Please go back to the Scanner documentation, where you will find that the default delimiter probably does what you want.
Khayla Matthews wrote:. . . numbers are separated by one or more spaces. . . .
Please explain exactly how you are running that code because I can't see how you can get 3 2 1 as an output.
java.util.Scanner[delimiters=[,\s+]][position=0][match valid=false][need input=false][source closed=false][skipped=false][group separator=\,][decimal separator=\.][positive prefix=][negative prefix=\Q-\E][positive suffix=][negative suffix=][NaN string=\QNaN\E][infinity string=\Q∞\E]
That shows how you can confuse yourself by creating two classes with such similar names.
Khayla Matthews wrote:. . . a previous, but similar, class . . .
I am not glad; it means you haven't worked out the solution yourself and you aren't learning as much as you could have. And please show us what they suggested as an answer.
. . . looked at the solution. Glad I did . . .
S Fox wrote:if that was the official solution, it's a horrible way to teach anyone. nobody would want to write code like that in the real world!
i think you can do this with a while loop, something like:
Agree; look at that repeated code.
S Fox wrote:. . . nobody would want to write code like that in the real world!
Yes, you can use a loop, but there is a serious problem with the loop you wrote. I am challenging you to find it. I would probably use a for loop, or you could follow Carey's suggestion.
i think you can do this with a while loop . . .
That's a big mistake. Thanking that C works the same as Java® is another mistake.
S Fox wrote:. . . when i learned C . . . i didn't re-learn them for java.
What makes you think there is any lying involved? There is a next token, but it is still in your fingers. If you read the documentation, you will see that some of its methods block and wait for input. It is waiting for input, and assumes that there will be more input as long as there is an input stream.
why would java intentionally lie that there is something next if there really isn't? . . .
It is the difference between intent (optmiistic prediction) and final outcome (pessimistic prediction). It is taken optmiisticallly to mean, “there might eventually be a next token.”
S Fox wrote:. . . "already has a next token" and "there might eventually be a next token" . . .
No, it is you interpreting it in a way different from what its make intended. If I say, “I'll go out and have some beer,” that is true when I leave home. If I fall over and break my leg, or get there and find they have run out of beer, I shan't drink any beer. But that doesn't make my original statement incorrect, or even inaccurate.
that's why it's lying. . . .
You are using somebody else's product, so you will have to use it as they designed it. But they didn't document its behaviour at all well, as Winston Gutkowski has pointed out before.
so to me it's weird they designed it like that.
That is what I meant about closing System.in, something I don't like to encourage. But maybe OP should try ctrl‑D (I think you use ctrl‑Z on Windows®) to see what happens. The loop doesn't wait on while (myScanner.hasNext()) ..., but on myScanner.nextInt(); so it doesn't terminate normally. It terminates by throwing an exception.
Junilu Lacar wrote:. . . When you type Ctrl+D. That will signal the end of input and terminate the loop normally. . . .
Campbell Ritchie wrote:The loop doesn't wait on while (myScanner.hasNext()) ..., but on myScanner.nextInt(); so it doesn't terminate normally. It terminates by throwing an exception.