jshell tool: opinions sought -- double-dash long-form command-line options
Jonathan Gibbons
jonathan.gibbons at oracle.com
Wed Aug 17 19:44:03 UTC 2016
For new code, I think 2 is to be preferred, with an optional minor
allowance for alternate forms of --help. But a clean modern 2 is OK too.
-- Jon
On 08/17/2016 12:35 PM, Robert Field wrote:
> I believe the reasonable choices are:
>
> (1) Kitch-sink: support new options with modern syntax and legacy
> options in legacy syntax and modern syntax. Disallow combined options.
>
> (2) Clean modern: Like jmod. All double-dash multiple-letter or
> single-dash single-letter. Allow combined single-letter options.
>
> -Robert
>
>
>
>> On Aug 17, 2016, at 12:05 AM, Michael Müller
>> <michael.mueller at mueller-bruehl.de
>> <mailto:michael.mueller at mueller-bruehl.de>> wrote:
>>
>> 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 <http://blog.mueller-bruehl.de/>
>> Web Development with Java and JSF: leanpub.com/jsf
>> <http://leanpub.com/jsf>
>> Java Lambdas and Parallel Streams: leanpub.com/lambdas
>> <http://leanpub.com/lambdas>
>>
>>
>> Am 17. August 2016 07:44:44 MESZ, schrieb Robert Field
>> <robert.field at oracle.com <mailto: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
>> <mailto: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>
>> <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 t! ypically 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
>> initialmodule. <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 verb! ose)
>> 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