On 10/5/16 3:34 AM, Alan Bateman wrote:
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
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.
-- Jon
