jshell tool: opinions sought -- double-dash long-form command-line options
Robert Field
robert.field at oracle.com
Wed Aug 17 19:35:11 UTC 2016
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> 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>:
> 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 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 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
> 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