On 3/28/12 5:35 PM, Richard Thomas wrote:
> System.out.println("enter the source document file name");
> *source = in.nextLine();// need to request 2x times to work--bug??*
> source = in.nextLine();
Davin already replied about this specific code segment, suggesting
that the problem was perhaps due to surrounding (but omitted) code.
Let me venture a guess that you've done other operations with the
scanner before this code segment, and that the scanner is not
"looking" where you think it is. For example, consider this short
transcript on the console, with program-generated lines preceded
by a << and human-typed input lines tagged with >>, and assuming
all lines end in the platform's line terminator sequence:
<< Enter a word:
<< enter the source document file name
Now, suppose that the code to work with this looks like this:
System.out.println("Enter a word:");
String word = in.next();
int wordLength = word.length();
System.out.println("enter the source document file name");
source = in.nextLine();// need to request 2x times to work--bug??
What actually happens? First, the program prints out "Enter a word:".
Then the program calls in.next() which is going to block waiting for
input--waiting for the person to type something.
Then the person types "hello\n" (I'll just use \n to represent the
enter key, which will be translated to the host platform's line
terminator sequence). Console input in Java is line-buffered by
default, so no matter how many words the person types, the enter
key must be pressed as well before any of the characters get
passed on to the scanner and processed.
After the person types enter/return, the entire line, including
the line termination character, is available for the scanner to
process. But what does the call to in.next() actually do?
First it skips over any whitespace (the default delimiter for
scanners) to the first non-whitespace character it can find--
here, the "h". Then it continues scanning over non-whitespace
characters until it finds another delimiter--here, the newline
(or the first character of the line termination sequence, to
be platform independent). Then it stops and returns the word
it found: "hello".
String word = in.next(); // returns "hello"
BUT ... where is the scanner looking after next() returns?
The scanner stops at the end of the word it returns--right
after that "o", but right before the line termination sequence.
If you call next() again, t will skip over any whitespace
(including line terminators) looking for the next word, so
that probably isn't an issue.
BUT ... the next scanner action is to call nextLine(). What
does nextLine() do? It starts with the very first character
the scanner is looking at, and scans up to and including the
very first line termination sequence it finds. It grabs
all the text before the line termination sequence, skips
over the line termination sequence, and leaves the scanner
looking at the very next character following that line
In this hypothetical example, the scanner was looking just
after the "o" in hello, right *at* the line terminator on
the end of the first line typed by the person at the
console. So it merrily does exactly what I described--
and returns an empty string, the sequence of characters
it saw just before the first line terminator it found.
It also leaves the scanner looking at the beginning of
the second line the person typed, so the second call does
In summary, I don't have any idea what your surrounding
code looks like, but I agree with Davin that the problem
lies there, and the behavior you are seeing is likely due to
mistaken assumptions about where the scanner is actually
looking (that is, it is still looking earlier in the
input sequence than you think, due to calls to scanner
methods like next() that are not line-oriented).
Hope that helps ...
Virginia Tech, CS Dept. Web-CAT: Web-based Center for Software Testing
114 McBryde Hall (0106) Automatic grading using student-written tests
Blacksburg, VA 24061 USA http://web-cat.org/