JShell doesn't provide a ToolProvider

[Robert Field]

On 11/16/16 15:00, forax at univ-mlv.fr wrote:
> So i respectfully disagree with Robert :)
>
> While the interactive mode of jshell is something important, being able to replay interactive sessions (stored in a file) automatically is in my opinion as important.
> If the module jdk.jshell provide an implementation for the interface ToolProvider inside the package jdk.internal.shell.tool, it can start JShellTool with exacly the same arguments as the main() does.
>
> Rémi

I respectfully AGREE with Rémi.

My arguments were for support of an InputStream parameter, and I agree 
that without that is better than nothing, so I have created:

     https://bugs.openjdk.java.net/browse/JDK-8169821

The InputStream could be addressed in the SPI by having one more default 
in ToolProvider, roughly:

     default int run(InputStream in, PrintStream out, PrintStream err, 
String... args) {
         return run(System.in, out, err, args);
     }

Maybe I was unclear --

On 10/04/16 20:42, Robert Field wrote:
 >
 > On 10/04/16 20:24, Jonathan Gibbons wrote:
 >> Hi Robert,
 >>
 >> When you invoke jshell from the command line through the command 
line launcher, there must surely be a simpler entry point that is 
invoked.  Command line entry points don't provide Java Preferences 
objects, for example. That being said, I agree that jshell does require 
an input stream, and that is not supported by this SPI.
 >
 > This is how main calls that entry-point --
 >
 >     public static void main(String[] args) throws Exception {
 >         new JShellTool(System.in, System.out, System.err, System.out,
 >                  System.out, System.err,
 >                  Preferences.userRoot().node("tool/JShell"),
 >                  Locale.getDefault())
 >                 .start(args);
 >     }
 >
 > The only additional parameter needed to match this form of use would 
be: InputStream in.


On 10/04/16 21:14, Robert Field wrote:
 >
 > On 10/04/16 21:06, Jonathan Gibbons wrote:
 >> I don't understand: on the one hand you say you don't want the tool 
to be an API, but then you say you want to fit in with the proposed new 
ToolProvider SPI.
 >
 > Sorry, I was unclear.  We don't want to turn the code of the tool 
into a tool component API.  There is an API the tool is built on, we 
want that as the only API.
 >
 > I do want access somewhere to launch the existing tool.

-Robert


>
> ----- Mail original -----
>> De: "Alan Bateman" <Alan.Bateman at oracle.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Envoyé: Mercredi 16 Novembre 2016 12:29:42
>> Objet: Re: JShell doesn't provide a ToolProvider
>> On 16/11/2016 09:23, Remi Forax wrote:
>>
>>> Hi all, hi Robert,
>>> currently, unlike javac or javadoc, there is no way to directly invoke jshell
>>> (JShellTool) because it lies in an internal package (which is a good idea).
>>>
>>> I think the module jdk.jshell should provide a java.util.spi.ToolProvider so i
>>> can embed jshell, like i can embed any dynmic langage runtimes, in my program
>>> instead of having to invoke it using the command line (without being able to
>>> control the exact version of jshell or even if jshell is present in case of a
>>> custom jdk image).
>>>
>> This was discussed as part of introducing the SPI [1], you'll see the
>> mails from Robert where he points out that this doesn't fit.
>>
>> -Alan
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/compiler-dev/2016-October/010379.html