RFR: 8344560: Add system property for patched runtime [v3]

[Severin Gehwolf]

On Mon, 25 Nov 2024 11:01:10 GMT, Alan Bateman <alanb at 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