RFR: JDK-8241883: (zipfs) SeekableByteChannel:close followed by SeekableByteChannel:close will throw an NPE

[Alan Bateman]

On 07/04/2020 17:18, Lance Andersen wrote:
> Hi all,
>
> Please review the fix for JDK-8241883, which addresses an issue with 
> Zip FS where multiple calls to SeekableByteChannel::close results in 
> an NPE.
>
> This issue was discovered while adding the additional Zip FS test 
> coverage for FileChannel and SeekableByteChannel
>
> Here is the diff for the patch:
> ——————————
> $ hg diff
> *diff -r f4c174bf0276 
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java*
> *--- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java   
>   Tue Apr 07 09:03:05 2020 -0400*
> *+++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java   
>   Tue Apr 07 11:38:29 2020 -0400*
> @@ -892,6 +892,10 @@
>
>
>       @Override
>       public void close() throws IOException {
> +            // Check to see if close() has been previously called
> +            if(!isOpen()) {
> +                return;
> +            }
>           // will update the entry
>           try (OutputStream os = getOutputStream(e)) {
>               os.write(toByteArray());
>
How robust is async close in the zip file system? Just wondering how it 
works when a SeekableByteChannel is being accessed in one thread when 
the zip file system is closed by another.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200407/22fd91db/attachment.htm>