David Flanagan wrote:
> I know that JSR 199 is not in community review yet, but I just read your
> yahoo groups post about the interim solution you're proposing for Tiger,
> and wanted to share some thoughts:
> 1) I don't think that the Command class should require subclasses to be
> named "Main" in order to be found by the find() method. This may be
> a useful default, but shouldn't be required. How about having
> findByPackage() methods which take the package name and assume Main
> as the classname, but also more general find() (or findByClass())
> methods that take a fully-qualified class name.
The mechanism for implementing a command (now tool) should not be specified
in the API, as it is up to the vendor of a JDK to implement them however
they want. I've removed those comments from the description of the API.
> 2) If Command and CommandNotFound are the only classes in the package,
> does it need a package of its own, or could it be put in java.util?
> If it must be in a javax package, then wouldn't javax.command be a
> more descriptive name than javax.shell? Or do you think that the
> package will grow to have more shell-type capabilities? (When I
> think of a shell, I think of things like command-line variable
> substituion, and the ability to specify a working directory. Unless
> you aim to add stuff like this, I think that javax.shell is not a
> good choice.)
Agreed. I've renamed it to java.tools;
> 3) Is then intent of this capability that it can be used with any
> external Command in any external JAR file? Or is it only for tools
> specifically shipped with a Java implementation? If the latter, then
> would Tool be a more descriptive name than Command?
> 4) I imagine that the implementation will include a configuration
> parameter somewhere that specifies the classpath for the
> getToolLoader() ClassLoader. Will, or should, that configuration
> information also include a list of allowed Command package or class
> names? If so, the the Command class could also easily have a "public
> static String availableCommands()" method. This doesn't seem
> critical, but might be useful if your implementation would support it
These are implementation details that should not be specified in the API.
> 5) Are there any interactions between your proposal and the Application
> Isolation API of JSR 121? Or Doug Lea's concurrency utils JSR? That
> is, would it be useful to build upon either of these frameworks, or
> to provide utility methods that run a tool in an Isolate, or that run
> it as a Future?
No, there is no intended interaction at all. These are not separate
threads or processes, nor are they run in an isolated VM. In any case,
JSR 121 is no longer a planned part of J2SE 1.5.
I'm copying these answers to the JSR199 mailing list, and I'll also be
sending an update of the API.