RFR JDK-8131023: JShell: System.in does not work

[Robert Field]

As the bug title states, System.in does not work from Snippets.  In a 
command line tool there is only one "in", even though the constructor 
for the tool takes a separate cmdIn and userIn.  So, for a command line 
tool to work these need to be unified.  However, though the JShell API 
is the recommended approach to creating new tools, some will choose to 
wrap the tool, say in a GUI.  In fact this has already been done.  Such 
a wrapped tool can have separate input channels.  Rather than changing 
the constructor for JShellTool to remove the userIn parameter, it would 
seem to leave more options open if a new constructor with just one input 
parameter (not named "cmdIn") was added which forwards to the old 
constructor.

More later...


On 08/25/16 08:23, Jan Lahoda wrote:
> Hi,
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8131023
>
> Langtools webrev:
> http://cr.openjdk.java.net/~jlahoda/8131023/langtools.00/
>
> JDK repository webrev:
> http://cr.openjdk.java.net/~jlahoda/8131023/jdk.00/
>
> Specdiff:
> http://cr.openjdk.java.net/~jlahoda/8131023/diff.00/jdk/jshell/execution/Util.html 
>
>
> Currently jshell forwards output from the agent to the main process. 
> With this patch, the input is also forwarded from the main process to 
> the agent. InputStream.read() is only called in the main process if it 
> has been called on the agent side; this is achieved by using an 
> artificial OutputStream in the agent->main process direction. On the 
> agent side, when an input is requested, a character is written to the 
> corresponding artificial OutputStream, the main process is about that, 
> reads from the actual input and sends the data back to the agent.
>
> In the tool, jline is used to actually read the input, as System.in is 
> switched in the raw mode. This requires a tweak in jline, to detect 
> the proper column on which the editing starts, to cover requests like:
>
> System.err.print("Prompt: "); System.err.flush(); System.in.read();
>
> Without the tweak, the line editor wouldn't unfortunately know about 
> the text written to the console (for supported terminals, at least). 
> (This tweak may be useful in any case for complex prompts that use 
> escape sequences; also for jjs.)
>
> An alternative would be to try to switch jline off while reading the 
> user's input. The advantage of using jline is that it allows to detect 
> Ctrl-C.
>
> Any feedback is welcome!
>
> Thanks,
>      Jan