RFR: 8159855: Create an SPI for tools
jonathan.gibbons at oracle.com
Wed Oct 5 15:19:51 UTC 2016
On 10/5/16 3:34 AM, Alan Bateman wrote:
> On 05/10/2016 10:54, Stephen Colebourne wrote:
>> 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
>> 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
> 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.
Informally, I think the common use case for this API is to get "same VM"
access to tools in the bin/ directory of the product image. That implies
there is an obvious name for each tool, and that there will be
documentation for the arguments that each tool that is available.
Also, in general, the doc comments for a module should contain details
of any services for general use, including details of how to access the
service (e.g. what name to use, in this case) and how to use it (info
about arguments, etc, in this case.) We are working on updating the
javadoc tool to better support the provision of such information.
More information about the core-libs-dev