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

[Robert Field]

Continued...

MultiplexingOutputStream.java

Was this changed so that it occurs in a single write that won't get 
interleaved?  Do we have this issue elsewhere?  The encoding is now 
complex enough that the special unrolling for 'void write(int b)' isn't 
justified.  Could be just:

byte[] a = { b };
write(a, 0, 1);

Thumbs up if those two issues (above and below) are addressed.

-Robert

On 08/25/16 10:37, Robert Field wrote:
> 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
>