RFR: JDK-815440: JRT filesystem loaded by JDK8 with URLClassLoader is not closable since JDK-8147460

Alan Bateman Alan.Bateman at oracle.com
Mon Apr 18 17:37:10 UTC 2016

On 18/04/2016 18:14, Xueming Shen wrote:
> Hi,
> Please help review the change for JDK-8154403
> issue: https://bugs.openjdk.java.net/browse/JDK-8154403
> webrev: http://cr.openjdk.java.net/~sherman/8154403/webrev/
> The direct trigger of the failure is that the test case is passing in 
> a null as parameter
> "env" to create a new jrt filesystem. The nio spec specifies that it 
> will trigger NPE. The
> existing implementation does not check the "null" and passes it 
> directly into
> JrtFileSystem's constructor, in which the "null" is interpreted as "a 
> not closable jrt file
> system" (A implementation detail).
> The fix is to add the "null check" in the provider and pass in "empty 
> map" in the test case.
> Alan, the original jrtfs implementation throws UOE in 
> JrtFileSystemProvider.getTheFileSystem(),
> is it better to just "silently" ignore the close request for the 
> "not-closable" jrt? I'm file with
> either way though.
L107 checks if env is null so that is not needed. Otherwise looks okay.

If someone is attempting to close the file system returned by 
FileSystem.getFileSystem(URI.create("jrt:/")) then something is wrong. I 
may have suggested to Sundar that this throw UOE because this method is 
specified to throw this for the default file system. It should be okay 
to keep that behavior.


More information about the core-libs-dev mailing list