jshell tool: opinions sought -- double-dash long-form command-line options
Jonathan Gibbons
jonathan.gibbons at oracle.com
Tue Aug 16 17:19:05 UTC 2016
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