Hi Alan,
The JVM does not look for the -m (or --module) option. Instead, it
checks if property "jdk.module.main" is non-null. If it is non-null
then the JVM uses the option name in its "Cannot use the following
option when dumping the shared archive" message, as in:
> $JAVA_TEST/bin/java -Xshare:dump -m my_mod
Error occurred during initialization of VM
Cannot use the following option when dumping the shared archive: -m
Unfortunately, it prints "-m" regardless of whether -m or --module was
specified.
Harold
On 7/18/2016 3:13 AM, Alan Bateman wrote:
On 18/07/2016 00:05, 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.
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/
A passing comment on unsupported_options (options not allowed when
using -Xshare:dump) then it has -m in the list. I assume that should
not be there. That is java launcher option, the VM don't see or
unrecognize it, also it's long form is --module.
-Alan
