0

Assuming I have something like this:

 x= (char) System.in.read();

     if(x == 'a') {
        // Do something;
     }

How much different is it from something like:

public void handle(KeyEvent event) {
        switch (event.getCode()) {
            case A: // Do something;
            case ENTER: // Do something else;
        }
    }

I mean when should I use the first and when the second? What are the pros and cons?

Asperger
  • 3,064
  • 8
  • 52
  • 100
  • 3
    They are completely different. One is a blocking read a character from standard input, the other one is a handler for a key event called by the event dispatcher in a GUI app. – pvg May 28 '16 at 21:00
  • @pvg Not specifically a GUI app, console based applications can be made event-driven. This is the classic case of the hollywood principle, and he's asking which way is preferred. – Vince May 28 '16 at 21:05
  • The first way is preferred for a simple command line program, and the second is preferred for a GUI program. – Peter Lawrey May 28 '16 at 21:07
  • @PeterLawrey thanks : ) – Asperger May 28 '16 at 21:22
  • 1
    @VinceEmigh there's no built-in way to do that in Java and `KeyEvent` is a an AWT event (nor is a generalized key event particularly meaningful in a console app, given the typical limitations) – pvg May 28 '16 at 22:01
  • @pvg No one said they were looking for a built-in way. `KeyEvent` specifies an event from a keyboard. You could use this class for your own purposes, following the "Dont reinvent the wheel" philosophy. Most production code relies on either 3rd party or self-written code - the JDK isn't a silver bullet, and contains [TONS of design flaws](http://stackoverflow.com/questions/31153006/why-is-scanner-implementing-iteratorstring/31153794#31153794). From what I see, he's simply asking which is the better way to handle key events, and event-based handling could easily be implemented. – Vince May 28 '16 at 22:08
  • 1
    @VinceEmigh Sure. You could also write a GUI app that collects event through your own implementation of InputStream.read or put your pants on head first but that would be equally silly. The bulk of KeyEvent is completely inapplicable to console apps. – pvg May 28 '16 at 22:24
  • @pvg No one said it even had to be `java.awt.KeyEvent`. The point was it's possible to have both ways, and that stuff matters in production code. No need to be rude. – Vince May 28 '16 at 22:34

1 Answers1

0

The two approaches are getting input from the user in two different ways.

The first is reading characters from the JVM's "standard input" stream. If you ran your application without redirecting standard input, this stream is likely to be coming from the "console window" where you launched the JVM. The keystrokes on the console window are processed by the console / OS line editor until the user types ENTER. When that happens a line of characters is delivered to the input stream ready to be read by the JVM / Java application.

The second is processing keyboard events directly. However, this only works in a GUI application. It only sees the keyboard events directed at the application's window(s).


I mean when should I use the first and when the second?

Use the first in a console-based where you don't need to see characters at the instance the user presses a key.

Use the second when you have a GUI based application and you want to get input from the user interactively.

What are the pros and cons?

That is self-evident from the above. However, there are a couple additional "cons".

  • With the System.in approach:

    • The System.in stream could be coming from a file. If you need to be sure (or as sure as possible) that you are talking to a real user, use System.console() ... and check that you don't get null.
    • If you want to see the user's characters as they are typed, you need to use a 3rd-party library.
  • With the EventHandler approach:

    • This won't work on a "headless" system.
    • It is heavy-weight on the Java side as well. Something on the Java side needs to deal with key-up / key-down events, echoing, line-editing, end so on. If you are intercepting the events in your code, it may well be your code that has to do the heavy lifting.
    • I don't think there is a way to use it without launching a window. (Otherwise there would be no way for the end-use to know where the "input focus" is for the characters that he / she is typing.)
Stephen C
  • 698,415
  • 94
  • 811
  • 1,216