Concatenated .gz files/streams

[Xueming Shen]

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.
> --
>
>