Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

print() problems

 
Al Rivarosa
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am just now learning to program in Java, and I am having a problem with getting user input after the print() statement runs. Instead of the cursor waiting for user input, it just runs through the rest of the code.
public class Shift {
/**
* The main program for the Shift class
*
*@param args The command line arguments
*/
public static void main(String[] args) {
BufferedReader console = new BufferedReader(new InputStreamReader(System.in));
System.out.print("Enter a String value ");
String number = null;
try {

number = console.readLine();
} catch (IOException e) {}
System.out.println(number);
}
}
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You will have to put the read part within a loop.
 
Al Rivarosa
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the help, but I was still not able to get it to work.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24212
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not sure what you mean by "it just runs through the rest of the code." The program you've written will work just as you'd expect, with two possible exceptions, both somewhat platform-dependent.
The first issue is that the prompt might not appear before you type the input. You can fix this by calling System.out.flush() after printing an incomplete line, like this:

The second issue is with line input buffering. Some operating systems will line-buffer the console input to this program; the problem arises because that buffering will interact with the buffering done by the BufferedReader class. Whenever you connect a BufferedReader to a line-buffered input source like System.in, you should add the optional second argument to the BufferedReader constructor, specifying a buffer size of 1 character (i.e., no buffering

With thrse changes your program should run as expected on any platform.
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Are you using some IDE or running the program in a console?
 
Al Rivarosa
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It still does not work, on my machine. But it runs fine on my friends computer. Could my PATH or CLASSPATH not be set correctly?
 
Al Rivarosa
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am using JEdit 4.1
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does it open up a MS DOS Console ?
 
Dirk Schreckmann
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Al,
Your posted code seems to work well for me.
Are you able to compile it on your computer?
 
Herb Schildt
Author
Ranch Hand
Posts: 253
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have heard of this problem before. The frustrating part is that your code works fine for me so I can't duplicate the problem. As to the cause of your problem, it seems that in some environments, a residual CR/LF remains in the console input buffer when the program is started. This residual CR/LF is being read when the readLine() method executes. Thus, your program appears to just "run through" the call to readLine(). To see if this is the cause of your trouble, try adding a second readLine() statement immediately after the first. The first readLine() will catch the residual CR/LF, the second will read your intput. If this works, then you will at least know what is happening.
BTW, what operating system are you using?
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ahem.
Funny, I just got done ranting about this sort of thing elsewhere.

Empty catch blocks are EEEVIL, EEEVIL, EEEVIL! Unless you're sure of what you're doing; there are some exceptions which we won't go into here. Any time you're not 100% sure what how to deal with an exception, do not ignore it. Replace this with:

Chances are good you will now see an error message here, giving a clue what the problem is. You never want to hide such an error message. Later on, for more user-friedly programs, you might log the error message to a file somewhere instead, and pop up a nicer looking message to the user instead. But e.printStackTrace() is a good quick default for now.
[ October 02, 2003: Message edited by: Jim Yingst ]
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One more thought: you might want to (temporarily) replace

with

This is useful for seeing exactly what sort of string you did read, if the problem has to do with carriage returns and line feeds as Herb suggests. If some of the chars you've taken in are not printable, this helps you see what they really are.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic