On Mon, 20 Apr 2026 08:32:09 GMT, Alan Bateman <[email protected]> wrote:
>> AFAIK, it's used by `JRTArchive`, IIRC. I might be wrong, though. The URLs
>> returned by ModuleReader are `jrt:/` type URLs at least.
>>
>>
>> jshell> var uri =
>> ModuleFinder.ofSystem().find("java.base").orElseThrow().open().find("java/lang/Object.class").get();
>> uri ==> jrt:/java.base/java/lang/Object.class
>>
>> jshell> Files.size(Path.of(uri));
>> $15 ==> 2479
>
> David is working on an "end to end" test that will run jlink to create a
> run-time image that contains classes compiled with preview features enabled
> in META-INF/preview. Running a test with the resulting run-time image, both
> with preview features enabled and disabled, will ensure that it works as
> expected. It will need to be run with the default config, and builds that
> were configured with `--enable-linkable-runtime` of course.
>
> But maybe your question is more about running the jlink tool itself with
> preview features enabled? I suspect `jlink -J--enable-preview` would be rare,
> but executing it with ToolProvider (and thus in-process) is important to test
> too.
The concern here is that running `jlink` on a JEP 493 enabled JDK (no jmods)
and on a JDK *with* JMODs give you the exact same custom runtime image. I.e. it
has to include both preview and non-preview versions if both are present for a
class. There is a test,
`test/jdk/tools/jlink/runtimeImage/PackagedModulesVsRuntimeImageLinkTest.java`
which tries to assert that.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29414#discussion_r3109370762
