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
