Re: [compress] Added in-memory support for zip and 7z

2016-11-04 Thread Stefan Bodewig
On 2016-11-01, M N wrote: >> read never indicates EOF as it stands, I think we should return -1 >> rather than 0 when position equals size. WDYT? > Yes, indeed the contract specifies to return -1 in this case so we > should change this. will do. >>> In resize() method there is also a danger to

Re: [compress] Added in-memory support for zip and 7z

2016-11-01 Thread M N
Hi Stefan, (...) > read never indicates EOF as it stands, I think we should return -1 > rather than 0 when position equals size. WDYT? Yes, indeed the contract specifies to return -1 in this case so we should change this. >> In resize() method there is also a danger to overflow integer

Re: [compress] Added in-memory support for zip and 7z

2016-10-22 Thread Stefan Bodewig
Hi Maciej patch applied. On 2016-10-22, M N wrote: > Going back to the fix - first I've done the homework and read the contract of > SeekableByteChannel.position(long) method. > It influences read() and write() operation. > Citation of the most important part: > "Setting the position to a

Re: [compress] Added in-memory support for zip and 7z

2016-10-22 Thread M N
... and patch is attached to Jira COMPRESS-327 From: M N Sent: Saturday, October 22, 2016 2:04:53 PM To: dev@commons.apache.org Subject: Re: [compress] Added in-memory support for zip and 7z All, OK, volatile won't hurt anyway. Going

Re: [compress] Added in-memory support for zip and 7z

2016-10-22 Thread M N
All, OK, volatile won't hurt anyway. Going back to the fix - first I've done the homework and read the contract of SeekableByteChannel.position(long) method. It influences read() and write() operation. Citation of the most important part: "Setting the position to a value that is greater

Re: [compress] Added in-memory support for zip and 7z

2016-10-20 Thread Stefan Bodewig
On 2016-10-20, wrote: > Even when a stream is not thread safe I try at least to make close() > safe/atomic as aborts and finalizers or shutdown hooks are natural > sources for concurrency – all using close(). true. > (However I guess it is less problematic for memory

Re: [compress] Added in-memory support for zip and 7z

2016-10-20 Thread Stefan Bodewig
On 2016-10-20, M N wrote: > I have created tests for SeekableInMemoryByteChannel and spot small error. Great, thanks Maciej. > Attached is a patch with tests and proposed fix. The mailing list is set up to strip attachments (at least I don't see any). Could you attach it to a JIRA issue?

AW: [compress] Added in-memory support for zip and 7z

2016-10-20 Thread ecki
Hello, Even when a stream is not thread safe I try at least to make close() safe/atomic as aborts and finalizers or shutdown hooks are natural sources for concurrency – all using close(). Using a AtomicBoolean or flag is good for that. (However I guess it is less problematic for memory

Re: [compress] Added in-memory support for zip and 7z

2016-10-20 Thread M N
Hi Stefan, I have created tests for SeekableInMemoryByteChannel and spot small error. Attached is a patch with tests and proposed fix. Regarding thread safety I think would be more clear to remove volatile and document a class as not thread safe. I think the need for thread safe

[compress] Added in-memory support for zip and 7z

2016-10-13 Thread Stefan Bodewig
Hi all actually it is SeekableByteChannel-support combined with a byte[] backed implementation of SeekableByteChannel. Over the past few days I've rewritten the zip and 7z packages to become independent of RandomAccessFile and thus no longer require writing to or reading from a file. The