jshell tool: opinions sought -- double-dash long-form command-line options

[Ben Evans]

+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
>>
>>
>