On passing --date to jrt-fs jar at build time

[Alan Bateman]

On 01/04/2025 08:52, Galder Zamarreno wrote:
>
>
>     I'm not sure what "test harness" and "test jar" means here but
>     just to say that jrt-fs.jar is in the JDK run-time.
>
>
> ^ Are you sure? The default make target, `exploded-image`, doesn't 
> build the jrt-fs.jar. Aside from `test`, `images` does build the jar.
>
>     When an IDE running on JDK X needs to build/run a project for
>     target JDK Y then it will use the jrt file system to access the
>     classes in the target JDK. jrt-fs.jar is the provider
>     implementation that JDK X will load to do this.
>
>
> If the jar does not mean, seems like an exploded image jdk won't work 
> for ^?

jrtfs provides access, via the file system API and provider mechanism, 
to the classes/resources in the "current" run-time image. It handles 
exploded builds and images builds.

jrtfs also provides access to the classes/resources in a remote/target 
JDK, think IDE running on JDK $X but targeting JDK $Y. Creating a jrtfs 
file system on JDK $X with home=JDK $Y will load the file system 
proivider from JDK $Y jrt-fs.jar. This is why the classes in jrt-fs.jar 
are compiled --release 8.

I think you are asking why the exploded build doesn't include 
jrt-fs.jar. I suppose it could but the exploded build is just an interim 
step in the JDK build and not something that a vendor would ship. If 
there were a strong need for an IDE running on JDK $X to target an 
exploded build of JDK $Y then it can be made it work but it seems a less 
interesting setup.

Hopefully it is starting to be clear that jrt-fs.jar is not tied to 
testing the JDK, it is needed in an images build to support IDEs (and 
other tools) that target the JDK.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250401/da5a5faa/attachment.htm>