Review for 7157656 (zipfs) SeekableByteChannel to entry in zip file... (original) (raw)

Alan Bateman Alan.Bateman at oracle.com
Wed Apr 18 08:32:25 UTC 2012

On 17/04/2012 22:23, Xueming Shen wrote:

Given the sequential nature of the zip stream, it's a kinda of hard to implement the position(long) method for a "pure" zip byte channel. You don't want to jump either backward or forward N bytes when writing and appending (we don't have a "position mapping" between the compressed and uncompressed data, so you simply can't "position" to a desired N pos when compressing), and for the same reason you don't want to jump back either when reading, the only "meaningful/doable" position(N) operation is when N> position() for reading, which is basically a "skip N - position() byte" operation. In order to implement the position(N), for writing, you have to write all the data without compression into a "buffer", you then can "position(N)" on it. And only do the real compression upon closing. For reading, you have to de-compress the whole zip entry into a buffer first, then build a channel on top of this buffer for the reading/ positioning. This is how newFileChannel is implemented now. -Sherman Right, a SeekableByteChannel allows for random access but you don't know in advance how the channel will actually be used, it may only be used for sequential access. Given that the zip provider supports FileChannel then maybe it could be implemented so that it switches (behind the scenes) to a FileChannel when position is invoked to seek to a position<current. For the read (or read+write) case then position>current can just skip as you suggest, the write-only case would have to switch to a FileChannel. It will likely to be tricky of course. BTW: This the comment was just a passing comment when looking at Paul's patch, it's of course a several issue/project that should preclude Paul's fix from going in.

-Alan

More information about the core-libs-dev mailing list