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
