On 11/16/16 15:00, fo...@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.bate...@oracle.com>
À: "Remi Forax" <fo...@univ-mlv.fr>, "core-libs-dev"
<core-libs-dev@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
