JShell tool: remove or keep default Edit Pad editor?

[mark.reinhold at oracle.com]

2016/10/11 17:51:41 -0700, robert.field at oracle.com:
> On 10/11/16 16:09, mark.reinhold at oracle.com wrote:
>> 2016/10/10 17:31:35 -0700, paul.sandoz at oracle.com:
>>> ...
>>> 
>>> One approach for an out of the box solution is to split out the editor
>>> functionality into a separate module and for jshell to define a
>>> service provider interface. Thereby on a full JDK distribution you can
>>> the same functionality but on a more minimal distribution it is not
>>> present.
>> 
>> That would be the "modular" way to do it.
> 
> That would certainly be doable.  If the critical concern is module 
> boundaries.  But that exposes the Edit Pad to use outside of jshell -- 
> is that an issue?

You can prevent undue exposure by defining the service type in the
jdk.jshell module and exporting its containing package only to the
new module that contains Edit Pad, something like this:

    module jdk.jshell {
        exports jdk.jshell.editor.spi to jdk.internal.editpad;
        ...
    }

    module jdk.internal.editpad {
        requires java.desktop;
        requires jdk.jshell;
        provides jdk.jshell.editor.spi.Editor
            with jdk.internal.editpad.EditorProvider;
    }

>> ...
>> 
>> Have you considered, at least on Unix systems, supporting the EDITOR
>> environment variable?  Yes, it might be platform-specific, but it's an
>> incredibly handy and reasonably standard way to tell random programs how
>> to use the editor of your choice.
> 
> Was tempted.  The jshell tool suspends the REPL while in the editor (so 
> they don't clash).  However some editors return immediately -- there is 
> a -wait option on /set editor for this case.

Every Unix tool I've ever seen that uses EDITOR has assumed that the
command defined by that environment variable will not return until the
editing operation is complete.  I think jshell can assume that too.

>                                               But of course, coming from 
> EDITOR there is no way to know if it needed. Between that, the platform 
> specific aspect, and how it would interact with /set and Preferences -- 
> it seemed a bit convoluted and shaky.  Still an option but it doesn't 
> solve the problem -- just another finger in the dike.

All too often we've built useful tools in the JDK but failed to make
them relate well to the environments in which they're actually used.
I'd hate to see jshell fall into the same trap.  Please reconsider
this.

- Mark