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

[Jan Lahoda]

Hi,

Langtools patch updated to reflect the comments is here:
http://cr.openjdk.java.net/~jlahoda/8131023/langtools.01/

How does it look?

Thanks,
     Jan

On 26.8.2016 20:11, Robert Field wrote:
> 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
>>
>