8194937: Inconsistent behavior of --validate-modules when combined with -m and other options

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

8194937: Inconsistent behavior of --validate-modules when combined with -m and other options

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
Reply | Threaded
Open this post in threaded view
|

Re: 8194937: Inconsistent behavior of --validate-modules when combined with -m and other options

Mandy Chung
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

On 6/20/18 11:40 PM, Alan Bateman wrote:

>
> 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