commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: svn commit: r759472 - in /commons/proper/compress/trunk/src/site: site.xml xdoc/examples.xml xdoc/index.xml xdoc/zip.xml
Date Sat, 28 Mar 2009 16:04:13 GMT
On 28/03/2009, Stefan Bodewig <bodewig@apache.org> wrote:
> On 2009-03-28, sebb <sebbaz@gmail.com> wrote:
>
>  >>>        <p>Reading entries from an ar archive:</p>
>  >>> <source><![CDATA[
>  >>> ArArchiveEntry entry = (ArArchiveEntry) arInput.getNextEntry();
>  >>> byte[] content = new byte[entry.getSize()];
>  >>> LOOP UNTIL entry.getSize() HAS BEEN READ {
>
>  > I thought the idea was that the ArchiveInputStreams would not allow
>  > one to read past the end of the entry, so one can just read until
>  > read() returns -1?
>
>
> I wrote that on the train last night while I was offline and committed
>  it this afternoon before reading my mail 8-)
>
>  I don't think AR is the only archiver that does not return -1 once you
>  read past the end of the current entry, nor am I convinced that it is
>  a good idea to expect the streams to do so.

I thought that was the main idea of the archive input stream.
IMO, it makes using the classes much easier.

AFAICS, the test cases currently assume it.

If users are not prevented from reading past the entry without calling
getNextEntry(), the input stream class can easily get lost.

>  The code of the examples should work and IMHO the API user should
>  rather rely on the entry's size than on the stream returning -1.  Are
>  we sure our streams return -1 on directory entries immediately?

That needs to be tested and fixed if not.

>  BTW, while catching up with mail I saw a lot of discussion going on
>  inside JIRA instead of on the dev list.  This may be a project
>  cultural thing, but to me JIRA is not the correct place for that.

I tend to agree, but it can be useful.

I've seen JIRA issues that have almost no information and so are hard
to follow; probably there was other information on the mailing list,
but if it's not referenced from the JIRA it can be hard to find later.

>  Stefan
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message