On Mon, 25 Nov 2024 11:01:10 GMT, Alan Bateman <al...@openjdk.org> wrote:
> I could use some background, the property itself seems like a hack, and those > tend to live too long. What state that might be patched is used to create the > new image? With JEP 493, one can link (run `jlink`) without `jmods` folder. Instead of using jmod archives for the class bytes they come from the modules image `lib/modules`. I.e. the run-time image. If the run-time image is itself patched - using `--patch-module` - the lookup used by the JEP implementation would observe patched classes. It's using `ModuleFinder/ModuleReference`. The `jrt:/` FS implementation - on the other hand - doesn't have visibility to module patches. The JRT FS implementation is being used for retrieving class bytes and answers size queries when jlink runs (when linked from the run-time image). > How does jlink know that a configuration has been modified and refuse to make > a new image. Depends what you mean by "configuration". For example, every non-class/non-resource file has a SHA512 sum which is being checked before using it as a result of a `jlink` run. > What part of the new image does not come from the jrt: file system? In this specific case listing of classes/resources from ModuleFinder/ModuleReference. It appears, though, that for module patches the URI of a class/resources has `file` scheme, while module image class/resources have `jrt` scheme. We could use that instead. Filter only `jrt` scheme resources. On the other hand, detecting module patching early would be nice as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22277#issuecomment-2497739774
