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

[Alan Bateman]

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