Is Caching JrtFileSystem acceptable?

Sundararajan Athijegannathan sundararajan.athijegannathan at
Tue Nov 3 06:00:10 UTC 2015

As Alan said, other thing async. closing of the file system, nothing 
really comes to mind. There is checkResource call in code to check that 
the resource exists before opening channel on it.. Is it possible to 
reproduce this on a smaller app?


On 11/2/2015 4:05 PM, Alan Bateman wrote:
> On 02/11/2015 09:48, Jayaprakash Arthanareeswaran wrote:
>> Hello,
>> We recently changed our code in Eclipse to support JRE 8 when loading
>> classes from a Java 9 images (discussion at [1]). The change was to 
>> use a
>> JrtFileSystem with a class loader. The file system is then cached and
>> re-used for every request to get something from the JRE 9 images. The 
>> code
>> is something like this:
>> URL url = Paths.get(jdkHome, "jrt-fs.jar").toUri().toURL();
>> URLClassLoader loader = new URLClassLoader(new URL[] { url });
>> FileSystem jrt = FileSystems.newFileSystem("jrt:/", env, loader);
>> After this change, we have started getting an NPE in the file system (We
>> are randomly hitting this and at this point no idea what is causing it):
>> Daemon Thread [Java indexing] (Suspended (exception 
>> NullPointerException))
>>     ByteArrayInputStream.<init>(byte[]) line: 106
>>     JrtFileSystem.newByteChannel(byte[], Set<OpenOption>,
>> FileAttribute<?>...) line: 600
>>     JrtPath.newByteChannel(Set<OpenOption>, FileAttribute<?>...) line:
>> 732
>>     JrtFileSystemProvider.newByteChannel(Path, Set<OpenOption>,
>> FileAttribute<?>...) line: 218
>>     Files.newByteChannel(Path, Set<OpenOption>, FileAttribute<?>...)
>> line: 361
>>     Files.newByteChannel(Path, OpenOption...) line: 407
>>     Files.readAllBytes(Path) line: 3152
>> I have confirmed that the JrtFileSystem that is used in the above 
>> stack and
>> what we cached are the same objects. And the path that is being 
>> passed in
>> the beginning is a valid JrtPath. I would like to know if this is a 
>> bug in
>> the file system implementation or something to do with our code.
>> Of course, I don't have the source for JrtFileSystem, so unable to debug
>> this further. Thanks for any pointers in trouble-shooting this further.
> I'm not aware of any issues here and there shouldn't be an issue 
> retaining the reference to the jrt FileSystem.
> As the jrt FileSystem is in the stack trace then it means that 
> Files.readAllBytes has been called with Path associated with the jrt 
> file system. It's not obvious how a NPE could arise after that. The 
> only thing that comes to mind is the file system being closed 
> asynchronously, I can't recall how the jrt file system handles that 
> (Sundar will know).
> However, just to establish the environment - is this IBM JDK 8 or an 
> Oracle/OpenJDK build of JDK 8? Also is the target image a regular JDK 
> 9 build or a Jigsaw build? There are changes to the jrt file system 
> code in the Jigsaw forest but this is mostly to support exploded builds.
> -Alan

More information about the jigsaw-dev mailing list