Review request 8136930: Simplify use of module-system options by custom launchers

[Mandy Chung]

> On Aug 8, 2016, at 3:51 AM, Alan Bateman <alan.bateman at oracle.com> wrote:
> 
> On 05/08/2016 21:11, Mandy Chung wrote:
> 
>> This patch renames the module-system options to GNU-style as specified
>> in JEP 293 [1] (see below for the new proposed option names).  This
>> addresses the problems discussed in [2] that the launcher will pass
>> the module-system options down to the VM in the form of <option>=<value>.
>> This provides a consistent way to configure the module system and
>> simplify use of module-system options by custom launcher.  This patch
>> also updates several JDK tools including jlink, jmod, jimage, jar,
>> javac, javap, javadoc, javah, jdeps such that the GNU-style
>> module-system options are consistent across all tools.
>> 
>> Webrev:
>>  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/gnu-options/webrev.00/
>> 
> One thing to check is java.c L1299 where it should have failed if has_arg is false (0).

1296             REPORT_ERROR (has_arg, ARG_ERROR5, arg);

If has_arg is false, REPORT_ERROR would return JNI_FALSE and won’t get to L1299.  With that said, the if (has_arg) statement is not strictly needed.

> Also since the initial module/class is being set here then maybe we should have -jar pick up the next arg rather than having two different ways to set pwhat.
> 

A long-standing behavior of the java launcher when ARG_CHECK fails it will print the usage message.  e.g. "java -jar”  missing the argument will print:
Error: -jar requires jar file specification
Usage: java [-options] class [args...]
           (to execute a class)
   or  java [-options] -jar jarfile [args...]
           (to execute a jar file)
where options include:
:
:

because ARG_CHECK sets printUsage = JNI_TRUE.  I discussed this with Kumar on ARG_CHECK setting printUsage.  He believes it’s a long standing bug in the launcher.

The launcher error message is clear and I think missing argument case for the new options should not need to print the usage.  We agree to follow up the -jar option as a separate issue since it may have compatibility concern.  That will make them consistent.

> launcher.properties. I wonder if "This option can be specified more than once" should be clearer than it can be used more than once with different module/packages. Alternatively maybe it should be just dropped from the usage output if the text ends up too wordy.
> 

OK, dropped.

> In javap.properties then there is a typo in "instead whitespace" (missing "of"). Also probably best to say a "file URL" instead of "URL" as I don't think it accepts an arbitrary URL.
> 

Fixed.

> I don't have any other comments, overall it's looking very good.

Thanks for the review.

Mandy