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