On Mon, 16 Dec 2024 18:40:19 GMT, Severin Gehwolf <sgehw...@openjdk.org> wrote:
>>> A different question would be what should happen if the module specified in >>> `--limit-modules` is **not** in the dependency graph of ALL-MODULE-PATH >>> modules. >> >> This seems a good candidate for an error as it's unexpected, IMO. I'll add a >> separate test case which exercises this and add code to prevent this: >> >> >> $ rm -rf ./build/limit-mods-test && >> ./build/linux-x86_64-server-release/images/jdk/bin/jlink --add-modules >> ALL-MODULE-PATH --module-path ./build/jmods --limit-modules jdk.net >> --verbose --output ./build/limit-mods-test >> Error: jdk.net not in module dependency graph, but specified with >> --limit-modules >> >> >> The same without limit modules: >> >> $ rm -rf ./build/limit-mods-test && >> ./build/linux-x86_64-server-release/images/jdk/bin/jlink --add-modules >> ALL-MODULE-PATH --module-path ./build/jmods --verbose --output >> ./build/limit-mods-test >> Linking based on the current run-time image >> com.bar.testmod >> file:///disk/openjdk/upstream-sources/git/jdk-jdk/./build/jmods/com.bar.testmod.jmod >> java.base jrt:/java.base (run-time image) >> java.compiler jrt:/java.compiler (run-time image) >> jdk.compiler jrt:/jdk.compiler (run-time image) >> jdk.internal.opt jrt:/jdk.internal.opt (run-time image) >> jdk.jdeps jrt:/jdk.jdeps (run-time image) >> jdk.zipfs jrt:/jdk.zipfs (run-time image) >> >> Providers: >> jdk.compiler provides com.sun.tools.javac.platform.PlatformProvider used >> by jdk.compiler,jdk.jdeps >> java.base provides java.nio.file.spi.FileSystemProvider used by java.base >> jdk.zipfs provides java.nio.file.spi.FileSystemProvider used by java.base >> jdk.compiler provides java.util.spi.ToolProvider used by java.base >> jdk.jdeps provides java.util.spi.ToolProvider used by java.base >> jdk.compiler provides javax.tools.JavaCompiler used by java.compiler >> jdk.compiler provides javax.tools.Tool not used by any observable module >> >> >> A similar - pre-existing - problem exists where `--limit-modules` would be >> outside the dependency graph of modules specified with `--add-modules`. But >> this would be for a different bug so as to prevent scope-creep. > >> But this would be for a different bug so as to prevent scope-creep. > > Filed https://bugs.openjdk.org/browse/JDK-8346299 for this. jlink --add-modules ALL-MODULE-PATH --limit-modules jdk.jfr --module-path jmods --output all-mods-limit-mods.image The set of observable modules only has `java.base` and `jdk.jfr` because of `--limit-modules`. Hence `com.baz.runtime` from `jmods` is not observable. `ALL-MODULE-PATH` adds all observable modules found on the relevant module paths are added to the root set. This matches the run-time behavior. $ java --list-modules -p com.baz.runtime.jar --add-modules ALL-MODULE-PATH --limit-modules jdk.jfr java.base@25-internal jdk.jfr@25-internal ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22494#discussion_r1887342424
