RFR: 8159855: Create an SPI for tools

[Alan Bateman]

On 05/10/2016 10:54, Stephen Colebourne wrote:

> Interesting.
>
> How likely is it that there will be more than one tool of a given name
> available? The method name findFirst() seems relatively odd for the
> lookup operation.
>
> I'd also note that the name string to pass in are "magic". There are
> no constants defined for callers to use. Since there is no obvious way
> in the API to find the vendor, this could get tricky across JDKs. Plus
> how would a caller know what arguments to pass if each vendors tool
> differs?
>
> Just being cautious about the use case being solved.
Many command line tools don't define an API and so not unheard of to 
find code that uses sun.tools.jar.Main.main or the main method of other 
tools. Also common to see code using ProcessBuilder or Runtime.exec to 
launch tools like jar. If the commonly used tools (jar, jdeps, ...) 
document their tool names in their module description then it will make 
it easier to run these tools in the same VM. It does mean that some 
tools will have both an API and a documented tool name but that 
shouldn't be an issue. I'm sure Jon has a lot to say on this topic, esp. 
with linking usage documentation and man pages.

As regards constants then not clear where something like this would live 
as it amounts to a registry. Also many of the tools are JDK or library 
specific and so wouldn't have a place in the standard/Java SE docs.

The firstFirst(String) method limits itself to tools that are visible 
via the system class loader. Sure, someone might decide to deploy lots 
of libraries that all claim to be the "hammer" tool but this is no 
different to many of the service providers mechanisms. One could have 
the ToolProvider define methods with the tool capabilities that would 
aid selection but that would complicate the API.

-Alan