Review request: JDK-8159596 Add java --dry-run

[Mandy Chung]

> On Jul 2, 2016, at 2:02 PM, Peter Levart <peter.levart at 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