There is a bug that has shown up on a number of projects, and it's kind of a deceptive bug, because it will result in programs that run properly on some systems, but not on others. In this case, it might run properly for you, but not for the submit system. None the less, it is a bug! The fact that you sometimes get away with it doesn't make it OK. Basically, the problem is this: when a Scanner object is garbage collected (or its closed method is called), the underlying Reader's close method is called. If the Reader's been doing any buffering, any unread characters in its buffer are lost! Thus for a particular input stream, you really only want to create a single Scanner, and pass it around from method to method. Having each method call create another Scanner object wrapped around the same input stream is asking for trouble.

The Bad Way

The code below does exactly what I just told you not to do.

If you run this with input 5 7, it prints out "5" and sits there waiting for more input to be entered! If you do enter a third number, say 8, then "8" gets printed out. The "7" got lost when the Scanner from the first call to method f() gets garbage collected, and its underlying Reader gets closed.

~/$ java TestA
5 7
5
  ← sitting there waiting for more input!

The Good Way

In contrast, the code below does things the right way. A single Scanner object for System.in is created, and it is passed around to other methods.

If you run this with input 5 7, the program prints out "5" then "7", just as you'd like.

~/$ java TestB
5 7
5
7