RFR: JDK-8218287: jshell tool: input behavior unstable after 12-ea+24 on Windows
Jan Lahoda
jan.lahoda at oracle.com
Wed Feb 13 14:45:03 UTC 2019
Hi,
When JShell was upgraded to use JLine 3.9.0, the input from which the
Terminal is reading had to be wrapped, so that JShell can detect Ctrl-C
while the user's code is running. The mechanism for this is that the
StopDetectingInputStream is actively reading the input to find out if
Ctrl-C was pressed. (And other characters are stored aside and returned
from the StopDetectingInputStream when JLine is reading from it.)
Unfortunately, it turns out this wrapping is not done as expected on
Windows (when using the Windows terminal). The issue is that the source
of input in the AbstractWindowsTerminal is a Reader, which is directly
used to read the input by JLine, and is also converted to an
InputStream, which is typically not used. And this InputStream is
wrapped by the StopDetectingInputStream. So when the
StopDetectingInputStream is trying to detect Ctrl-C, it may "steal" an
input character, which is then missing in the Reader used by JLine, and
hence is lost (the StopDetectingInputStream has it stored aside, but it
is never read from it).
The proposed patch is to not use the Reader that is the source of input
directly, but rather create a new one based on the wrapped InputStream.
Webrev: http://cr.openjdk.java.net/~jlahoda/8218287/webrev.00/
JBS: https://bugs.openjdk.java.net/browse/JDK-8218287
How does this look?
Thanks,
Jan
More information about the kulla-dev
mailing list