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