JShell tool: remove or keep default Edit Pad editor?

[Robert Field]

On 10/11/16 16:09, mark.reinhold at oracle.com wrote:
> 2016/10/10 17:31:35 -0700, paul.sandoz at oracle.com:
>> IMO i think you should drop it, for many of the reasons you have
>> stated. I suspect we may come to regret this dependency later on.
> I agree.
>
>      $ ls -l java.desktop.jmod jdk.jshell.jmod
>      -rw-r--r-- 1 mr green  12M 2016-10-09 03:55 java.desktop.jmod
>      -rw-r--r-- 1 mr green 387K 2016-10-09 03:55 jdk.jshell.jmod
>      $
>
> It sure would be nice to be able to link a custom image that contains
> jdk.jshell without dragging in all of java.desktop, as it does now.
>
>> 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?

The Edit Pad doesn't have any particularly interesting differences from 
the use of any external editor -- except that we know it exists.  Any 
mechanism by which we could know where an editor was would work.

>
> 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.  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.

>
> - Mark

Thanks,
Robert