0

The Java Shell REPL's line input on Windows doesn't behave the way line input behaves in most other Windows console applications:

  1. The Ctrl+Left Arrow key combination does not go to the start of the previous line.
  2. The End-of-File character is Ctrl+D (like Unix) instead of Ctrl+Z.
  3. The cursor disappears when scrolling using the horizontal arrow keys.
  4. While typing there is a short lag (about 0.1s) until each letter typed appears.

This happens with both Java 9 and 10. By contrast, the Kotlin REPL does not exhibit this strange behaviour. Nor do Java's BufferedReader.readLine() or Scanner.nextLine() methods when using System.in, or System.console().readLine().

My questions:

  • Why is the Java Shell using this kind of line input? (I mean does it provide any particular benefit to compensate for it being harder to use?)

  • Is there a configuration to tell it to use the normal method of user input?

  • What Java API method is it using to read the user input (just so I can remember not to use it myself)?

DodgyCodeException
  • 5,963
  • 3
  • 21
  • 42
  • 1
    Sounds like you're seeing the same „[_JDK-8191640 : [Windows] JShell Defectively Wraps Lines And Mangles Input in JDK9_](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8191640)“ bug I raised about a year ago. – deduper Dec 19 '18 at 01:32

1 Answers1

0

The JShell tool uses JLine for its line editing. Thus, it behaves the same whether used on Windows, Mac or Linux. For example, the ctrl-b and ctrl-f keystrokes move the cursor backwards and forwards.

One of the advantages is that it gives you customized keystrokes (mainly tab completion and a few other things). You can get a list of these keystrokes, using the following command:

/help shortcuts

The disadvantages are as stated by the OP. I don't think it's possible to change the REPL to use another line-input method.

Klitos Kyriacou
  • 10,634
  • 2
  • 38
  • 70