RFR: 8345259: Disallow ALL-MODULE-PATH without explicit --module-path [v11]

[Alan Bateman]

On Tue, 17 Dec 2024 11:45:56 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this extension to #22609 which now disallows `ALL-MODULE-PATH` without explicit `--module-path` option or a non-existent module path. In addition, this fixes a bug mentioned in #22609 when `ALL-MODULE-PATH` and `--limit-modules` are used in combination. It failed earlier and passes now due to alignment of `ModuleFinder`s. With this patch JEP 493 enabled builds and regular JDK builds behave the same in terms of `ALL-MODULE-PATH`.
>> 
>> When an explicit module path is being added, there is no difference. All modules on that path will be added as roots. Tests have been added for the various cases and existing tests updated to allow for them to run on JEP 493 enabled builds. Thoughts?
>> 
>> Testing:
>> - [x] GHA, `test/jdk/tools/jlink` (all pass)
>> - [x] Added jlink test.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

I think it helps to think of `--add-modules ALL-MODULE-PATH` as `--add-modules java.base,java.compiler,java.datatransfer, .. jdk.xml.dom,jdk.zipfs`.

This leads `jlink --add-modules ALL-MODULE-PATH --limit-modules jdk.net` to create an image with "all modules". This may be surprising on first glance but it's the recursive enumeration so `jdk.net` (which is just `jdk.net` and `java.base`), plus the modules specified to `--add-modules`.

Note that we have issues at run-time with this combination, and at run-time there are other possible tokens that can be used too. Not for here, this issue has always existed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22494#issuecomment-2552073700