RFR: JDK-8241883: (zipfs) SeekableByteChannel:close followed by SeekableByteChannel:close will throw an NPE
Alan Bateman
Alan.Bateman at oracle.com
Tue Apr 7 19:30:09 UTC 2020
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>
More information about the nio-dev
mailing list