On Thu, 6 May 2021 07:41:00 GMT, Alan Bateman <[email protected]> wrote:
>> Jason Zaugg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove redundant cast from previous commit.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1235:
>
>> 1233: synchronized(ch) {
>> 1234: return ch.position(pos).read(bb);
>> 1235: }
>
> I think it's okay to include the update to EntryInputStream, that part looks
> fine, as does the directly use of the FileChannel positional read.
>
> I'm still mulling over the case where ch is not a FileChannel as I would
> expected it to capture the existing position and restore it after the read. I
> think this is the degenerative case when the zip file is located in a custom
> file system that doesn't support FileChannel. In that case, positional read
> has to be implemented on the most basic SeekableByteChannel. It would only be
> observed when mixing positional read ops with other ops that depend on the
> current position.
Here are all the references to `ch`.
this.ch = Files.newByteChannel(zfpath, READ);
...
this.ch.close();
...
ch.close(); // close the ch just in case no update
...
if (ch instanceof FileChannel fch) {
return fch.read(bb, pos);
} else {
synchronized(ch) {
return ch.position(pos).read(bb);
}
}
...
long ziplen = ch.size();
...
ch.close();
It appears the only position-dependent operation called `read(ByteBuffer)`.
This is performed together with the `pos` call within the `synchronized(ch)`
lock.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3853
