Currently the new BuiltInGzipDecompressor class inherits directly from JDK Inflater, but I suspect I should extend BuiltInZlibInflater instead.
I'd lean the other way. It's not really a supertype of BuiltInZlibInflater and neither are public types. It's not really an Inflater, either; it may be worth either supporting that interface or using an Inflater member rather than inheritance, since it only calls public methods. Either way, it's an existing confusion in the compression type hierarchy, and if it calls for any additional testing it can be ignored in this issue.
Is it worthwhile to encapsulate the state label and associated variables into a private inner class (BuiltInGzipDecompressor.java, first FIXME comment)?
Since the code is already implemented and tested, refactoring it for a slightly cleaner implementation of a user-opaque, RFC-compliant library doesn't seem like a reasonable condition for committing it.
DecompressorStream currently supports two concatenation modes via a pseudo-ifdef ("final boolean useResetPartially"): resetPartially(), which avoids any additional buffer copies at a cost of uglifying the Decompressor interface with this new method; or regular reset() + setInput() to recopy any "excess" bytes (that is, from stream N+1) at the end of stream N. The amount of recopying in the latter case is dependent on the buffer sizes (typically 64KB around here) and sizes of the concatenated gzip streams/members, but in general it won't be much. Barring strong disagreement, I'll go with the latter approach and clean up all the resetPartially() stuff in the next (hopefully final) version of the patch.
Agreed; the penalty for re-copying once per stream is light enough that it can be endured for other codecs' API considerations.
Any last-minute qualms about hardcoding the concatenation behavior? It would simplify the patch slightly and seems to be the preferred approach, so that's my plan for the next version.
Sounds fine to me. It may cause faults in some containers, but those are probably bugs covered over by this one.