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

Michael Müller michael.mueller at mueller-bruehl.de
Wed Aug 17 07:05:48 UTC 2016


Hi Robert,

What about Java itself?

java -version

Thus, keep it.

Keep
-cp ...
--class-path ...
But elimate
-classpath ...

Just my 2cts
-- 
Herzliche Grüße, Best regards
Michael Müller

Twitter: @muellermi
Blog: blog.mueller-bruehl.de
Web Development with Java and JSF: leanpub.com/jsf
Java Lambdas and Parallel Streams: leanpub.com/lambdas


Am 17. August 2016 07:44:44 MESZ, schrieb Robert Field <robert.field at oracle.com>:
>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