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
$ jlink --add-modules ALL-MODULE-PATH --module-path build/jmods --limit-modules
jdk.net --output ./build/test-img
This creates an image with jdk.net and its transitive dependences which is the
existing behavior, right? We are trying to revisit `--add-modules
ALL-MODULE-PATH` with `--limit-modules` in the future.
> "transitive closure of named modules plus the modules added with
> --add-modules" as {java.base, a, b, c}
Yes. That's how it is implemented as
https://openjdk.org/jeps/261#Limiting-the-observable-modules describes:
> (The transitive closure computed for the interpretation of the
> --limit-modules option is a temporary result, used only to compute the
> limited set of observable modules. The resolver will be invoked again in
> order to compute the actual module graph.)
So jlink sets up the finder that limits the observability and compute the
module graph from the roots using this finder.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/22494#issuecomment-2551955652
