Hi, please review this cleanup change to remove the ExistingChannelCloser facility in zipfs.
Some technical details about why this existed can be found in this mailing list thread, where Sherman explained its original purpose: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059839.html. At that time we didn't dare to remove it and deferred to further investigation. Now, when looking at the close() implementation of ZipFileSystem during review of JDK-8225507, I had a closer look to exChannelCloser as well and found that it should definitely be removed. Its original purpose was to keep a backing file and channel for InputStreams that were still open while the sync() method was called to update a zip file on disk. However, in its current state, a zip file is only synced to disk by sync() during close(), at a time when all InputStreams should already be closed. Closing of the streams is done at the beginning of method close(), in line 466ff. Closing of any open InputStream would remove it from the list named "streams". After that, it must be assured that no InputStreams get created, of course. This is accomplished by calling ensureOpen() under readLock, whenever an InputStream shall be created. The first step of close() though is to set the ZipFileSystem to state "closed", so these checks should all fail. I have, however, found one location where this ensureOpen check was missing and added it. jdk/nio/zipfs tests still pass. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8239556.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8239556 Thanks Christoph
