> 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

Reply via email to