Discussion:
8194937: Inconsistent behavior of --validate-modules when combined with -m and other options
Alan Bateman
2018-06-21 06:40:20 UTC
Permalink
The java `--validatate-modules` option is a very useful option to scan
all modules to identify a wide range of issues such as conflicts,
duplicate modules in a directory, modules shadowed by modules of the
same name, malformed module descriptors and more.

We originally implemented this option as "launcher helper" where it runs
after the VM is started. This creates a chicken 'n egg scenario where
starting the VM might fail due to issues that the validation should
catch. To avoid that, the VM starts up with a minimal boot layer, just
java.base, which is enough to allow the launcher helpers to run before
the launcher exits. This works okay but it the effect of ignoring
options such as --add-modules and -m that would normally specify the
module roots. This just means that f you specify any of these options
with --validate-module then the module path will be validated as
expected but bad values specified to these other options are ignored.

To get the option handling consistent, I'd like to move the validation
from being a launcher helper so that it runs as part of the module
system initialization (only when --validate-module is specified of
course).  This allows the option to be combined with other options that
specify module name. It also allows the option to be used with other
"exiting options" such as -version, --list-modules and --describe-module.

The webrev with the changes is here. Note that the validation has not
changed, this is mostly a house move with some expansion of the tests to
cover combinations of options that we didn't test in the original
implementation.
    http://cr.openjdk.java.net/~alanb/8194937/webrev/

-Alan
mandy chung
2018-06-21 14:52:15 UTC
Permalink
The change looks good. I'm glad that we get rid of the need for the
minimal boot layer for validation and gets the option handling consistent.

thanks
Mandy
Post by Alan Bateman
The java `--validatate-modules` option is a very useful option to scan
all modules to identify a wide range of issues such as conflicts,
duplicate modules in a directory, modules shadowed by modules of the
same name, malformed module descriptors and more.
We originally implemented this option as "launcher helper" where it runs
after the VM is started. This creates a chicken 'n egg scenario where
starting the VM might fail due to issues that the validation should
catch. To avoid that, the VM starts up with a minimal boot layer, just
java.base, which is enough to allow the launcher helpers to run before
the launcher exits. This works okay but it the effect of ignoring
options such as --add-modules and -m that would normally specify the
module roots. This just means that f you specify any of these options
with --validate-module then the module path will be validated as
expected but bad values specified to these other options are ignored.
To get the option handling consistent, I'd like to move the validation
from being a launcher helper so that it runs as part of the module
system initialization (only when --validate-module is specified of
course).  This allows the option to be combined with other options that
specify module name. It also allows the option to be used with other
"exiting options" such as -version, --list-modules and --describe-module.
The webrev with the changes is here. Note that the validation has not
changed, this is mostly a house move with some expansion of the tests to
cover combinations of options that we didn't test in the original
implementation.
    http://cr.openjdk.java.net/~alanb/8194937/webrev/
-Alan
Loading...