Loading ...
Sorry, an error occurred while loading the content.

Re: JSR 199 comments

Expand Messages
  • Neal Gafter
    ... 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
    Message 1 of 1 , Aug 14, 2003
    • 0 Attachment
      David Flanagan wrote:
      > Neal,
      >
      > 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?

      Yes. Changed.

      > 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
      > naturally.

      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.

      Regards,
      Neal
    Your message has been successfully submitted and would be delivered to recipients shortly.