RFR: 8345259: When linking from the run-time image ALL-MODULE-PATH is not accepted
Alan Bateman
alanb at openjdk.org
Tue Dec 3 15:29:40 UTC 2024
On Mon, 2 Dec 2024 18:25:22 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:
> Please review this bug fix for using `jlink` when linking from the run-time image. For regular JDK builds which include the `jmods` folder, that path is automatically added as the `--module-path` when not otherwise specified on the command line. For JDK builds with JEP 493 enabled, the `jmods` folder doesn't exist and the list of module roots needs to be computed from the system modules. However, since `jdk.jlink` isn't allowed to be added to the list of output modules when linking from the run-time image, the default module path doesn't include `jdk.jlink` and modules depending on `jdk.jlink`, currently only `jdk.jpackage`. This seems a sensible default since otherwise linking using ALL-MODULE-PATH fails, while it works with a JDK build including JMODs. See the bug for details about the issue.
>
> 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 same. Thoughts?
>
> Testing:
> - [x] GHA, `test/jdk/tools/jlink` (all pass)
> - [x] Added jlink test.
I'm in two minds as to whether we should do anything here.
ALL-MODULE-PATH means all observable modules on the module path but here, it's all observable modules minus jdk.jlink or any module that directly requires jdk.jlink. This is hard to reason about, and not exactly right either because any filtering should be any module that transitively requires jdk.jlink.
As background, the original motivation for ALL-MODULE-PATH was Maven build. It has always been supported by jlink too but I can't recall, or find, why we did that. Maybe Mandy can remember. In JEP 261, it is listed as being valid for both compile-time and run-time, but also mentions link-time.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/22494#issuecomment-2514878505
More information about the core-libs-dev
mailing list