On 3/07/2016 8:09 AM, Mandy Chung wrote:
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.
I asked earlier if loading the main class impacted the way the module
system was initialized - in which case the difference here and with
-version is obviously significant.
David
-----
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
