RFR(L) 8136930: Simplify use of module-system options by custom launchers

[Daniel D. Daugherty]

On 7/17/16 5:05 PM, harold seigel wrote:
> Hi,
>
> Please review these Hotspot VM only changes to process the seven 
> module-specific options that have been renamed to have gnu-like 
> names.  JDK changes for this bug will be reviewed separately.
>
> Descriptions of these options are here 
> <http://openjdk.java.net/jeps/293>.  For these six options, 
> --module-path, --upgrade-module-path, --add-modules, --limit-modules, 
> --add-reads, and --add-exports, the JVM just sets a system property.  
> For the --patch-module option, the JVM sets a system property and then 
> processes the option in the same way as when it was named -Xpatch.
>
> Additionally, the JVM now checks properties specified on the command 
> line.  If a property matches one of the properties used by one of the 
> above options then the JVM ignores the property.  This forces users to 
> use the explicit option when wanting to do things like add a module or 
> a package export.

Based on conversations with Harold, the JVM will _silently_ ignore the
specific properties if they are specified on the command line. Silently
ignoring the properties will likely lead to bugs being filed even if we
put a line or two in a man page somewhere. It seems useful for us to
issue a warning or an error if the user tries to specify properties on
the command line that we don't want to be specified.

I poked around the bugs and I don't see a rationale for the silently
ignore behavior. Can someone please explain?

Dan


>
> The RFR contains two new tests.  Also, many existing tests were 
> changed to use the new option names.
>
> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8136930
>
> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/
>
> The changes were tested with the JCK lang and VM tests, the JTreg 
> hotspot tests, and the RBT hotspot nightlies.
>
> Thanks, Harold