jshell tool: opinions sought -- double-dash long-form command-line options
Ben Evans
benjamin.john.evans at gmail.com
Wed Aug 17 06:16:34 UTC 2016
That makes sense to me - I'd say go for it.
Thanks,
Ben
On Wed, Aug 17, 2016 at 11:14 AM, Robert Field <robert.field at oracle.com> wrote:
> If jmods does not support legacy single-dash multiple-letter options, then
> should jshell?
>
> Should we trim it down to --
>
> --class-path <path> Specify where to find user class files
>
> --module-path <module path>... directory of modules.
> -p <module path>
>
> --upgrade-module-path <module path>... directory of modules that
> replace upgradeable modules
>
> --add-modules <modulename>[,<modulename>...] root modules to resolve
>
> --startup <file> One run replacement for the start-up definitions
>
> --no-startup Do not run the start-up definitions
> -n
>
> --feedback <mode> Specify the initial feedback mode. The mode may be
> predefined (silent, concise, normal, or verbose) or
> previously user-defined
>
> -q Quiet feedback. Same as: --feedback concise
>
> -s Really quiet feedback. Same as: --feedback silent
>
> -v Verbose feedback. Same as: --feedback verbose
>
> -J<flag> Pass <flag> directly to the runtime system.
>
> -R<flag> Pass <flag> to the remote runtime system.
>
> --help Print this synopsis of standard options
> -h
>
> --version Version information
>
> --full-version Full Version information
>
> Eliminating --
>
> -classpath <path> Specify where to find user class files
> -cp <path>
>
> -help Print this synopsis of standard options
>
> -version Version information
>
> -fullversion Full Version information
>
> Note: -qq is switched to -s. And, per Jon's suggestion, changed the
> spelling of --no-startup and --full-version to include separating dashes.
>
> With this, single-letter options could be combined: e.g. -nq
>
> -Robert
>
>
> On 08/16/16 10:19, Jonathan Gibbons wrote:
>>
>> Ben,
>>
>> The argument about consistency between tools was intended to be specific
>> to the syntax and semantics of specific options, like --class-path,
>> --module-path, --add-modules, etc.
>>
>> I didn't mean it to extend to "all ways of specifying a classpath", as in
>> "--class-path", "-classpath", and "-cp".
>>
>> jmods, for example, is a new tool, that only supports --class-path (not
>> -classpath, -cp)
>>
>> -- Jon
>>
>> On 08/16/2016 10:12 AM, Ben Evans wrote:
>>>
>>> +1 to not mixing options.
>>>
>>> +1 to using JOptSimple
>>>
>>> It's also worth pointing out that one at least one major supported
>>> platform (Mac), the shortcuts are not all present by default, so while
>>> one can just say "javac" and it works, "jshell" (or "jjs") do not work
>>> out of the box. This is apparently due to legacy Apple packaging
>>> requirements that we can do nothing about, and is highly annoying.
>>>
>>> However, it does weaken the argument that arguments should be entirely
>>> consistent between tools, because the end user would have had to
>>> engage in a certain amout of platform hackery to make jshell work in
>>> the same way as the rest of the pre-Java 7 tools in $JAVA_HOME/bin
>>>
>>> I'd therefore argue that this is evidence in support of dropping the
>>> older-style of options and using the modern double-dash style as the
>>> default, along with whatever shortcuts / additional accommodations
>>> make sense.
>>>
>>> Just my 2c,
>>>
>>> Ben
>>>
>>> On Tue, Aug 16, 2016 at 10:33 PM, Jonathan Gibbons
>>> <jonathan.gibbons at oracle.com> wrote:
>>>>
>>>> Other new tools are using JOptSimple, so that is certainly a reasonable
>>>> route, but that would (probably) imply dropping old-style options like
>>>> -classpath and -cp. For a new tool, that would be very reasonable.
>>>>
>>>> I agree that mixing old-style options and combined single letter options
>>>> is
>>>> a bad idea.
>>>>
>>>> -- Jon
>>>>
>>>>
>>>> On 08/16/2016 09:47 AM, Robert Field wrote:
>>>>
>>>>>> On Aug 16, 2016, at 8:07 AM, Jonathan Gibbons
>>>>>> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>>
>>>>>> wrote:
>>>>>>
>>>>>> Robert,
>>>>>>
>>>>>> Strong input: options that are common across tools should be the same
>>>>>> across tools, for example, the set of module options. You're already
>>>>>> suggesting that, so that's good.
>>>>>>
>>>>>> Additional input: double-dash options are typically a short series of
>>>>>> words separated by hyphens (instead of concatenated words), so that
>>>>>> makes
>>>>>> for --no-startup instead of —nostartup.
>>>>>
>>>>>
>>>>> Ah! Good point.
>>>>>
>>>>>> Note that double-dash options should allow '=' as a separator instead
>>>>>> of
>>>>>> white-space, as in --class-path=my:class:path
>>>>>> This is not typically spelled out in detail in command line help, but
>>>>>> there is typically a footnote to that effect at the end of the help.
>>>>>
>>>>>
>>>>> Right. I was pointed at JOpt-Simple since it does option parsing. I
>>>>> don’t think I’ll use it since error handling seems to lack the control
>>>>> I
>>>>> need. But, from that, I saw the =arg requirement. That should be easy
>>>>> to
>>>>> hand-craft.
>>>>>
>>>>> It also allows combining single-letter single-dash options, like -nq
>>>>> instead of -n -q. Given the multi-letter single-dash options, I’m not
>>>>> sure
>>>>> that makes sense to do.
>>>>>
>>>>> (continued)
>>>>>
>>>>>> -- Jon
>>>>>>
>>>>>> On 08/15/2016 10:35 PM, Robert Field wrote:
>>>>>>>
>>>>>>> We would like the jshell tool to roll-out using the more modern
>>>>>>> double-dash options. Note though that it will ship in the jdk/bin
>>>>>>> directory
>>>>>>> where almost all commands use legacy option formats.
>>>>>>>
>>>>>>> Below I propose options for jshell, as this is not a black-and-white
>>>>>>> decision, I'd very much like input....
>>>>>>>
>>>>>>> Current jshell options are --
>>>>>>>
>>>>>>> -classpath <path> Specify where to find user class files
>>>>>>> -cp <path> Specify where to find user class files
>>>>>>> -startup <file> One run replacement for the start-up
>>>>>>> definitions
>>>>>>> -nostartup Do not run the start-up definitions
>>>>>>> -feedback <mode> Specify the initial feedback mode. The mode
>>>>>>> may
>>>>>>> be
>>>>>>> predefined (silent, concise, normal, or
>>>>>>> verbose)
>>>>>>> or
>>>>>>> previously user-defined
>>>>>>> -q Quiet feedback. Same as: -feedback concise
>>>>>>> -qq Really quiet feedback. Same as: -feedback
>>>>>>> silent
>>>>>>> -v Verbose feedback. Same as: -feedback
>>>>>>> verbose
>>>>>>> -J<flag> Pass <flag> directly to the runtime system.
>>>>>>> Use one -J for each runtime flag or flag
>>>>>>> argument
>>>>>>> -R<flag> Pass <flag> to the remote runtime system.
>>>>>>> Use one -R for each remote flag or flag
>>>>>>> argument
>>>>>>> -help Print this synopsis of standard options
>>>>>>> -version Version information
>>>>>>> -fullversion Full Version information
>>>>>>>
>>>>>>> java options are mostly single-dash options, the current double-dash
>>>>>>> options are --
>>>>>>>
>>>>>>> -cp <class search path of directories and zip/jar files>
>>>>>>> -classpath <class search path of directories and zip/jar files>
>>>>>>> --class-path <class search path of directories and zip/jar files>
>>>>>>> A : separated list of directories, JAR archives,
>>>>>>> and ZIP archives to search for class files.
>>>>>>> -p <module path>
>>>>>>> --module-path <module path>...
>>>>>>> A : separated list of directories, each directory
>>>>>>> is a directory of modules.
>>>>>>> --upgrade-module-path <module path>...
>>>>>>> A : separated list of directories, each directory
>>>>>>> is a directory of modules that replace upgradeable
>>>>>>> modules in the runtime image
>>>>>>> -m <module>[/<mainclass>]
>>>>>>> --module <modulename>[/<mainclass>]
>>>>>>> the initial module to resolve, and the name of the
>>>>>>> main
>>>>>>> class
>>>>>>> to execute if not specified by the module
>>>>>>> --add-modules <modulename>[,<modulename>...]
>>>>>>> root modules to resolve in addition to the initial
>>>>>>> module.
>>>>>>> <modulename> can also be ALL-DEFAULT, ALL-SYSTEM,
>>>>>>> ALL-MODULE-PATH.
>>>>>>> --limit-modules <modulename>[,<modulename>...]
>>>>>>> limit the universe of observable modules
>>>>>>> --list-modules [<modulename>[,<modulename>...]]
>>>>>>> list the observable modules and exit
>>>>>>> --dry-run create VM but do not execute main method.
>>>>>>> This --dry-run option may be useful for validating
>>>>>>> the
>>>>>>> command-line options such as the module system
>>>>>>> configuration.
>>>>>>>
>>>>>>> Of these, --class-path, --module-path, --add-modules, and maybe
>>>>>>> --upgrade-module-path seem appropriate for jshell.
>>>>>>>
>>>>>>> Proposed for jshell --
>>>>>>>
>>>>>>> -classpath <path> Specify where to find user class files
>>>>>>> -cp <path>
>>>>>>> --class-path <path>
>>>>>>>
>>>>>>> -p <module path> directory of modules.
>>>>>>> --module-path <module path>...
>>>>>>>
>>>>>>> --upgrade-module-path <module path>... directory of modules that
>>>>>>> replace upgradeable modules
>>>>>>>
>>>>>>> --add-modules <modulename>[,<modulename>...] root modules to
>>>>>>> resolve
>>>>>>>
>>>>>>> --startup <file> One run replacement for the start-up
>>>>>>> definitions
>>>>>>>
>>>>>>> --nostartup Do not run the start-up definitions
>>>>>>
>>>>>>
>>>>>> Would be better as --no-startup
>>>>>
>>>>>
>>>>> Y
>>>>>
>>>>>>> -n
>>>>>>>
>>>>>>> --feedback <mode> Specify the initial feedback mode. The mode
>>>>>>> may
>>>>>>> be
>>>>>>> predefined (silent, concise, normal, or
>>>>>>> verbose)
>>>>>>> or
>>>>>>> previously user-defined
>>>>>>>
>>>>>>> -q Quiet feedback. Same as: --feedback concise
>>>>>>>
>>>>>>> -qq Really quiet feedback. Same as: --feedback
>>>>>>> silent
>>>>>>>
>>>>>>> -v Verbose feedback. Same as: --feedback
>>>>>>> verbose
>>>>>>>
>>>>>>> -J<flag> Pass <flag> directly to the runtime system.
>>>>>>>
>>>>>>> -R<flag> Pass <flag> to the remote runtime system.
>>>>>>>
>>>>>>> --help Print this synopsis of standard options
>>>>>>> -help
>>>>>>> -h
>>>>>>>
>>>>>>> -version Version information
>>>>>>> --version
>>>>>>>
>>>>>>> -fullversion Full Version information
>>>>>>> --fullversion
>>>>>>
>>>>>>
>>>>>> ?? --full-version ??
>>>>>
>>>>>
>>>>> Probably, y.
>>>>>
>>>>> Thanks much,
>>>>> Robert
>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Robert
>>>>>
>>>>>
>>
>
More information about the kulla-dev
mailing list