> On Jul 2, 2016, at 2:02 PM, Peter Levart <peter.lev...@gmail.com> wrote: > > What about extending the behavior of -version option so that when it is > specified together with other startup options like -mp, -m, -cp, MainClass, > ... it would behave just like --dry-run has been designed to work?
I don't see any issue with a new —-dry-run option that gives a clear intended usage. I don’t like recommend the existing -version option to be used for dry run. Although java -version starts the module system, it just assumes the default root module. > Would such combinations of options be hard to parse/detect/validate ? It’s just an existing behavior that can be changed. But I don’t think making -version for dry run is the right thing to do and requiring java -version must specify the main entry point (at least -m if launching a modular app). > For example, what to do if someone specifies -version in combination with > -mp, -addmods, but no -m ? Would we still try to resolve the modules and > print the version or fail and with what? The launcher should fail if there is no main class or main module specified even before it creates the VM. java -version assumes the default root module and not requiring any main entry point specified (that’s one difference between java -version and —-dry-run) -—dry-run opens more opportunity to add diagnostics information. For example you can run java -Xdiag:resolver —-dry-run <all other options> that will print the resolver traces for diagnostic. java -XshowSettings:args —-dry-run <all other options> @argfiles This could print the launcher/VM arguments, as Paul suggested. > Specifying just -mp by itself currently prints usage help. This is a bug in the existing launcher argument processing that ARG_CHECK should return false instead of true. I checked with Kumar and he would have to do archeology why it is implemented that way for long time. I have a patch fixing the argument processing on the module-system options that should not print usage help. > Having an explicit --dry-run option at least does not have those dilemmas and > defines the behavior explicitly when some startup options are missing - the > same behavior as without --dry-run. > Exactly. > In order to put more weight into --dry-run, I suggest extending its behavior > to report to the stdout, the result of resolving the modules when > successfull. Are you aware of -Xdiag:resolver? Mandy