RFR: 8159855: Create an SPI for tools

[Robert Field]

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.

>
> If you want to expose some tool-like API, you clearly can do so, and 
> it can take whatever stream and other parameters you want to expose.  
> But doesn't JShell already expose a richer API that clients can use? 
> Can you not provide an easy entry point in that package?

In theory, we could put it there -- but they are very very different 
unrelated levels -- I'd certainly rather not mix them up.

-Robert

>
> -- Jon
>
>
> On 10/4/16 8:42 PM, 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.
>>
>>>
>>> If you want a richer API, why do you not export a public API for 
>>> others to access and use?
>>
>> The tool is currently in: jdk.internal.jshell.tool
>>
>> We don't want the tool to be an API.
>>
>> We could change the package to not be internal and then have one 
>> class with one method -- but that seems overkill.
>>
>> I'd much rather find a way that it could fit with what you are 
>> developing.
>>
>> -Robert
>>
>>
>>
>>>
>>> -- Jon
>>>
>>>
>>>
>>> On 10/4/16 6:37 PM, Robert Field wrote:
>>>> I like the idea of this SPI.  And I'd like the jshell tool to 
>>>> launchable in this manner,
>>>>
>>>> Unfortunately the shape of the SPI would not allow for this. The 
>>>> current entry-point (which is in an internal package) is --
>>>>
>>>>     /**
>>>>      * The constructor for the tool (used by tool launch via main 
>>>> and by test
>>>>      * harnesses to capture ins and outs.
>>>>      * @param cmdin command line input -- snippets and commands
>>>>      * @param cmdout command line output, feedback including errors
>>>>      * @param cmderr start-up errors and debugging info
>>>>      * @param console console control interaction
>>>>      * @param userin code execution input, or null to use IOContext
>>>>      * @param userout code execution output  -- 
>>>> System.out.printf("hi")
>>>>      * @param usererr code execution error stream  -- 
>>>> System.err.printf("Oops")
>>>>      * @param prefs preferences to use
>>>>      * @param locale locale to use
>>>>      */
>>>>     public JShellTool(InputStream cmdin, PrintStream cmdout, 
>>>> PrintStream cmderr,
>>>>             PrintStream console,
>>>>             InputStream userin, PrintStream userout, PrintStream 
>>>> usererr,
>>>>             Preferences prefs, Locale locale)
>>>>
>>>> Some of these could defaulted, but not all.
>>>>
>>>> Any ideas?
>>>>
>>>> Thanks,
>>>> Robert
>>>>
>>>>
>>>>
>>>> On 10/04/16 16:46, Jonathan Gibbons wrote:
>>>>> Resend with non-mostly-empty subject line!
>>>>>
>>>>> -- Jon
>>>>>
>>>>> On 10/04/2016 04:39 PM, Jonathan Gibbons wrote:
>>>>>> Core-libs folk,
>>>>>>
>>>>>> Please review the following change to add a new service provider 
>>>>>> class
>>>>>>     java.util.spi.ToolProvider
>>>>>>
>>>>>> which can be used provide simple "command-line" access to select JDK
>>>>>> tools, without starting a new JVM.
>>>>>>
>>>>>> The following tools are updated to provide access through the new 
>>>>>> SPI:
>>>>>>     javac, javadoc, javap, jdeps
>>>>>>
>>>>>> It is expected that additional tools will also be updated to 
>>>>>> provide access,
>>>>>> but that will be done separately.
>>>>>>
>>>>>> Compiler-dev folk may wish to review the changes to the langtools 
>>>>>> repository.
>>>>>>
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8159855
>>>>>> Webrev: http://cr.openjdk.java.net/~jjg/8159855/webrev.03/
>>>>>> API: 
>>>>>> http://cr.openjdk.java.net/~jjg/8159855/api.02/java/util/spi/ToolProvider.html
>>>>>>
>>>>>> -- Jon
>>>>>
>>>>
>>>
>>
>