This looks much better and I can confirm it works in our set up too. Thanks Alan!
Regards, Jay ________________________________ From: Alan Bateman <alan.bate...@oracle.com> Sent: Friday, March 10, 2017 8:42 AM To: Jayaprakash Artanareeswaran; jigsaw-dev@openjdk.java.net Subject: Re: Referring to a different --system On 10/03/2017 06:09, Jayaprakash Artanareeswaran wrote: > Hello, > > I remember there was an open issue about not being able to use a different > JDK 9 (different than the current one) for class lookup. I raised this > question some time back and the following solution was suggested: > > <http://permalink.gmane.org/gmane.comp.java.openjdk.jigsaw/820>http://permalink.gmane.org/gmane.comp.java.openjdk.jigsaw/820 > > At that point this solution only worked when the compiler was from a JDK 8 > and not across different versions of JDK 9. This continues to be the case > even today with Eclipse. > > For convenience, the code proposed was this: > > URL url = Paths.get(jdkHome, "jrt-fs.jar").toUri().toURL(); > URLClassLoader loader = new URLClassLoader(new URL[] { url }); > FileSystem fs = FileSystems.newFileSystem(URI.create("jrt:/"), > Collections.emptyMap(), loader); > > Even today when I run the compiler with ea+159 and trying load JRT from > ea+153, I can clearly see that the JrtFileSystem returned is still pointing > to ea+159. > > But I also noticed Javac is able to refer to different JDK 9 without any > issue with --system., which makes me wonder if we should adjust our code in > some way too. JDK 8 does not have a `jrt` file system provider so the above code allows it to be loaded from the target run-time image when needed. A small nit in the above is that the path to jrt-fs.jar should be created with Paths.get(jdkHome, "lib", "jrt-fs.jar"). JDK 9 has a built-in `jrt` file system provider. In the above code fragment then your URLClassLoader does parent delegation and so the built-in `jrt` file system provider will be loaded, nothing will be loaded from jrt-fs.jar. This is why it accesses the "local" jdk-9+159 image rather the "remote" jdk-9+153 image. In any case, things have moved on significantly since that thread in early 2015. The `jrt` file system provider was updated to support access to other run-time images. This is done by specifying a key of "java.home" in the map that you use to configure the file system. The map value is the file system location of the runtime image. Can you try this: FileSystem fs = FileSystems.newFileSystem(URI.create("jrt:/"), Map.of("java.home", target)); where `target` is a string with the location of the target run-time image. -Alan
