On Tue, 17 Dec 2024 11:45:56 GMT, Severin Gehwolf <sgehw...@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
