jshell tool: opinions sought -- double-dash long-form command-line options
Robert Field
robert.field at oracle.com
Tue Aug 16 05:35:52 UTC 2016
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
-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
Thanks,
Robert
More information about the kulla-dev
mailing list