RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v13]
Severin Gehwolf
sgehwolf at openjdk.org
Thu Dec 21 09:39:55 UTC 2023
On Tue, 19 Dec 2023 19:14:42 GMT, Mandy Chung <mchung at openjdk.org> wrote:
>> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - Disallow packaged modules and run-time image link
>> - Only check for existing path when not a scratch task
>>
>> When using a run-time image link and the initial build was produced with
>> the --keep-packaged-modules option, we don't need to check existing
>> paths to the location where packaged modules need to be copied. This
>> breaks the --verbose output validation.
>
> FWIW. [f623930](https://github.com/mlchung/jdk/commit/f623930cd529085ddb730a60b7facf106ea01955) for your reference. I pulled your branch and refactored and made suggestions to the code while I was walking through the code. Some observations:
>
> The constants such as the pathname of the timestamp file and the internal file listing
> per-module non-class non-resource files are part of jlink. I move the constants to
> `JlinkTask`to follow where `OPTIONS_RESOURCE` is defined.
>
> `JRTArchive` scans the class and resource files of a given module from the runtime image.
> It should also read `fs_$MODULE_files` to find the list of non-class and non-resource files.
>
> The current implementation checks if a file is modified lazily when `Entry::stream`
> is called and so it has to remember if file modification has been checked and
> warning has been emitted. I think doing the file modification check eagerly
> when `collectFiles` is called would simplify the code.
>
> For maintainability, better to move the reading of and writing to `fs_$MODULE_files`
> together in a single class rather than separated in `JRTArchive` and `JlinkResourcesListPlugin`.
> I move them to `JRTArchive.ResourceFileEntry` for now. There may be a better place.
Thanks, @mlchung! I'll incorporate your refactoring into the PR and will address review feedback in the new year. Thanks for the review!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1865943588
More information about the core-libs-dev
mailing list