Concatenated .gz files/streams

[Martin Buchholz]

Thanks for the improvements.
Everything looks good to me,
but here are some additional suggestions:

Rename n to "members" to make it a little clearer.
  38             int n = rnd.nextInt(10) + 1;

Also use a random size with the GZIPInputStream constructor

  69         GZIPInputStream gzis = new GZIPInputStream(
  70                                    new ByteArrayInputStream(dst),
someotherrandomsize);

I find this kind of code difficult to review.
It's trickier than it looks.

Martin

On Sun, May 23, 2010 at 12:47, Xueming Shen <xueming.shen at oracle.com> wrote:
> Martin Buchholz wrote:
>>
>> One can argue this change doesn't go far enough,
>> and that one should be able to perform operations
>> that motivated the existence of the multiple member feature,
>> like skip to the next gzip member and to inspect the filename
>> and extra fields in the gzip header, but that's a much bigger
>> change.
>>
>> Probably GZIPInputStream shouldn't extend InflaterInputStream,
>> but too late for that.
>>
>
> One thing we might be able to do is to have a GZIPFile to provide access to
> those
> various header fields and individual member set, should request come in.
>
> Webrev has been updated accordingly.
>
> #int n = rnd.nextInt(100) % 10 + 1;
>
> should be just rnd.nextInt(10) + 1. I started with doing 100 of concatenated
> gz...
>
>
> #probably should do some cleanup on src, srcBAOS, srcBytes.
> #src is written to srcBAOS, then turned back into a byte[],
> #which seems pointless to me.
>
> I use the BAOS to concatenated the byte[] arrays (there are n of src
> arrays), don't want to
> handle it myself.
>
> Thanks,
> Sherman
>
> --
>
>
>> the returned values from readHeader and readTrailer
>> should be documented.
>>  --
>>
>> 174         int n = 10;
>> I would write this kind of code as
>> int n = 2 + 2 + 6;
>> for clarity.
>>
>> --
>> Probably readHeader should call crc.reset() twice,
>> before and after reading the header,
>> and then remove all calls to crc.reset() after calling
>> readHeader.
>> --
>>
>> typos:
>> OutputStram
>> jusr
>> --
>>  38             int n = rnd.nextInt(100) % 10 + 1;
>> Isn't this just rnd.nextInt(10) + 1?
>> --
>> the test should close gzis.
>> --
>> probably should do some cleanup on src, srcBAOS, srcBytes.
>> src is written to srcBAOS, then turned back into a byte[],
>> which seems pointless to me.
>> --
>>
>>
>
>