Newbie again. "Java Keyboard input" is a failure as a google search. What isn't?

[Lew]

That isn't Java.

Not nearly so as Lew.

tom

tom is not correct. I'm marginally less case sensitive than Java. I
certainly would not presume to tell tom how to spell his own name.

I'm sensitive to certain fundamental case issues, like how to spell "Java" and
other proper nouns, and of course, the word "I" in English. Spelling it "i"
is just tomfoolery.

 

[Arne Vajhøj]

Yes. But I wonder: Does anyone know a well-known Java
program (a program that is used by many people) that reads
what a user types with the keyboard from System.in?

Even if someone would come up with such a program here,
I think they are very rare.

They probbaly are.

But so what?

Such well known Java programs are usually not written by
people that have to ask in cljp on how to do keyboard input.

People that ask that are typical in the process of learning
the Java language.

And then console suddenly makes a lot more sense.

So why should I recommend something that I deem to be used
hardly ever in applied programming?

Do you teach small children to use a tricycle or do you let
them start by driving car because they will eventually
be driving a car?

Arne

 

[Arne Vajhøj]

Errrrr.... WHY?!?!?!?

It seems perverse to go to the overhead of building a complete WIMP user
interface to do

for ( int c = System.in.read(); c> -1; c = System.in.read()) {
char ch = (char) c;
/* now do something with ch */
}

In practice something like the following would be more useful:

string readLineFromStdin() {
StringBuffer buffy = new StringBuffer();
bool reading = true;

while ( reading) {
int c = System.in.read();

switch (c) {
case 10:
case 13:
case -1:
reading = false;
break;
default:
buffy.append( (char)c);
break;
}
}
return buffy.toString();
}

although in anything but the simplest utility programs you'd probably do
something a touch more sophisticated than that.

No - you would do it a lot simpler than that in any program.

BufferedReader or Scanner will save a lot of code.

Arne

 

[Stefan Ram]

But if what you want to write right now is an interactive command-line
program, then System.in is the only thing that helps you

When one wants to read characters (like German Umlauts) with
the console encoding and this console encoding differs from
the system encoding (as sometimes under Windows), sometimes,
its better to wrap java.io.FileDescriptor.in with the
required encoding than to use System.in. -- And then,
suddenly, a Swing-program to do the same, might not be much
more difficult anymore.

(However, to apply Swing beyond toy programs, one should
know about model-view-controller-separation and event-based
design.)

 

[Mike Barnard]

No - you would do it a lot simpler than that in any program.

BufferedReader or Scanner will save a lot of code.

As I'm finding out, thanks. However, would the above teach me anything
about 'how it works' even if it is overly wordy?

 

[Stefan Ram]

It seems perverse to go to the overhead of building a complete WIMP user
interface to do
for ( int c = System.in.read(); c > -1; c = System.in.read()) {

The OP said »reading input from the keyboard«.

»System.in« might be associated with any file or device
whatsoever on program start-up, beyond the control of the
Java-program running. So, the program can not know whether
»System.in« is connected with the keyboard at all.

This is not just a remote possibility. Instead »redirecting«
System.in is used often.

A JTextField /is/ certainly associated with the keyboard,
which is what was asked for: »reading input from the keyboard«.

 

[Tom Anderson]

When one wants to read characters (like German Umlauts) with the console
encoding and this console encoding differs from the system encoding (as
sometimes under Windows), sometimes, its better to wrap
java.io.FileDescriptor.in with the required encoding than to use
System.in.

Aha, i'd never thought of that.

I am a little perplexed by this, though; given that System.in is a stream
rather than a reader, i would have thought character encoding didn't enter
into it. Could you elaborate on what goes wrong in the case you mentioned?

And then, suddenly, a Swing-program to do the same, might not be much
more difficult anymore.

Perhaps. But it won't work so well over ssh .

tom

 

[Stefan Ram]

Aha, i'd never thought of that.
I am a little perplexed by this, though; given that System.in is a stream
rather than a reader, i would have thought character encoding didn't enter
into it. Could you elaborate on what goes wrong in the case you mentioned?

Sorry, I did confuse this with »System.out«, which /has/ an
encoding as a PrintStream.

However, a part of my point still is valid: When using
»System.in«, the programmer gets raw bytes and needs to be
able to choose the correct encoding himself, when wrapping
»System.in« into other objects that accept an encoding.
And when he then wants to write his German Umlauts to the
console, he sometimes needs to adjust the output encoding.
Doing this even portably might be a challenging task.

Swing should already be set up to accept any common
Unicode-character from the keyboard and display any common
Unicode-character in the GUI, well at least every character
from ISO-8859-1.

 

[Martin Gregorie]

Perhaps. But it won't work so well over ssh .

Depends on where you're sitting: if that's in front of a Windows box
using PuTTY then of course you're right, but if, like me, you're sitting
in front of a laptop with an X-term server running and X11 forwarding
enabled, then running a Swing GUI over ssh works just fine.

 

[Simon Brooke]

As I'm finding out, thanks. However, would the above teach me anything
about 'how it works' even if it is overly wordy?

If I hadn't thought it would, I wouldn't have posted it...

Underneath anything that reads from an input stream in Java is that basic
method read() returning an int, -1 in the case of end of stream,
otherwise 0-255 indicating the byte read. This may seem odd given that
Java characters are sixteen bit, but remember that this language was
designed as a language primarily for small embedded systems. At it's
lowest levels it's quite simple and even primitive.

 

[Stefan Ram]

Swing should already be set up to accept any common
Unicode-character from the keyboard and display any common
Unicode-character in the GUI, well at least every character
from ISO-8859-1.

public class Main implements java.lang.Runnable, java.awt.event.ActionListener
{ static final javax.swing.JFrame frame = new javax.swing.JFrame();
static final javax.swing.JTextField input = new javax.swing.JTextField();

public void run()
{ input.addActionListener( this );
frame.add( input ); frame.pack(); frame.setVisible(true); }

public void actionPerformed( final java.awt.event.ActionEvent event )
{ javax.swing.JOptionPane.showMessageDialog( frame, input.getText() );
System.exit( 0 ); }

public static void main( final String[] args )
{ javax.swing.SwingUtilities.invokeLater( new Main() ); }}

1. Text can be entered (edited) and terminated with the return key.
2. Text will be displayed in a message box.
3. User presses [OK].
4. Program terminates.

 

[Arne Vajhøj]

The OP said »reading input from the keyboard«.

»System.in« might be associated with any file or device
whatsoever on program start-up, beyond the control of the
Java-program running. So, the program can not know whether
»System.in« is connected with the keyboard at all.

This is not just a remote possibility. Instead »redirecting«
System.in is used often.

A JTextField /is/ certainly associated with the keyboard,
which is what was asked for: »reading input from the keyboard«.

It is absolutely not certain that JTextField is associated with
the keyboard.

Sure you can not redirect it. But you can have a context with
no Swing support. Very easily.

Arne

 

[Arne Vajhøj]

As I'm finding out, thanks. However, would the above teach me anything
about 'how it works' even if it is overly wordy?

No.

Not unless you count "learning good 1980 C code programming
using Java as language".

Arne

 

[Arne Vajhøj]

If I hadn't thought it would, I wouldn't have posted it...

Underneath anything that reads from an input stream in Java is that basic
method read() returning an int, -1 in the case of end of stream,
otherwise 0-255 indicating the byte read. This may seem odd given that
Java characters are sixteen bit, but remember that this language was
designed as a language primarily for small embedded systems. At it's
lowest levels it's quite simple and even primitive.

The fact that chars are 16 bit does not have much relevance for
a method returning bytes (which are 8 bit).

Arne

 

[Arne Vajhøj]

When one wants to read characters (like German Umlauts) with
the console encoding and this console encoding differs from
the system encoding (as sometimes under Windows), sometimes,
its better to wrap java.io.FileDescriptor.in with the
required encoding than to use System.in. -- And then,
suddenly, a Swing-program to do the same, might not be much
more difficult anymore.

As a rule of thumb then I would say that the need to go beyond
plan US ASCII makes GUI (Swing or SWT) attractive compared
to console.

But I still think that it makes sense to start with console.

Arne