Java Shell在Windows下行输入异常：原因、配置及使用API咨询

首先，你观察到的这些输入行为差异确实存在于Java 9/10的jshell中，下面针对你的三个问题逐一解答：

1. Java Shell为何采用此类行输入方式？是否有特定优势抵消其易用性不足？ #

jshell之所以采用这种和Windows常规控制台不同的输入行为，核心原因是它依赖了JLine这个Java终端库来实现高级REPL功能。JLine的设计目标是提供跨平台一致的终端交互体验，它在类Unix系统上能很好地支持语法高亮、代码自动补全、命令历史搜索、多行编辑等高级功能——这些都是传统BufferedReader或Scanner这类简单输入方法做不到的。

但在Java 9/10时期，JLine对Windows原生控制台的适配还不够完善，导致出现了你提到的快捷键不兼容、光标异常、输入延迟等问题。这种设计的优势在于，它能给jshell带来远超普通控制台程序的交互能力（比如在类Unix系统上体验非常流畅），只是在Windows平台的早期版本中牺牲了部分原生易用性来换取跨平台的高级功能。

2. 是否可通过配置使其使用常规用户输入方式？ #

当然可以，有几种方式能让jshell切换到Windows常规的输入行为：

• 禁用JLine启动jshell：启动时添加--no-jline参数，比如执行jshell --no-jline。这样jshell会回退到使用标准的System.in输入处理，和BufferedReader.readLine()这类方法的行为完全一致，你提到的Ctrl+左箭头跳转、Ctrl+Z结束输入等问题都会消失。
• 升级Java版本：Java 11及以后的版本对JLine的Windows适配做了不少优化，很多输入异常问题已经被修复。如果可以升级，建议尝试更新到较新的LTS版本，比如Java 17或21，能获得更流畅的Windows控制台体验。
• 使用Windows Terminal：替代传统的CMD或PowerShell，Windows Terminal对终端标准的支持更好，能减少光标消失、输入延迟这类渲染层面的问题。

3. 它使用了哪类Java API方法读取用户输入？以便避免使用该方法。 #

jshell并没有直接使用System.in相关的标准输入API，而是基于JLine库的终端交互API来处理用户输入。JLine会根据不同平台封装底层的终端输入逻辑（比如在类Unix系统调用ncurses，Windows调用原生控制台API），以此实现高级编辑功能。

如果你想避免这类输入行为，直接使用Java标准库中基于System.in的输入方法即可，比如你提到的：

• BufferedReader.readLine()
• Scanner.nextLine()
• System.console().readLine()

这些方法都是直接读取标准输入流，完全遵循Windows控制台的原生输入行为，不会出现jshell的那些异常问题。

内容的提问来源于stack exchange，提问作者DodgyCodeException