Concatenated .gz files/streams
xueming.shen at oracle.com
Sun May 23 19:47:03 UTC 2010
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
> 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
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
#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.
> 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
> 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.
More information about the core-libs-dev