Concatenated .gz files/streams
martinrb at google.com
Sun May 23 22:35:54 UTC 2010
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),
I find this kind of code difficult to review.
It's trickier than it looks.
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
>> 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
> 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