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