On Wed, 28 Aug 2024 19:56:04 GMT, Lance Andersen <lan...@openjdk.org> wrote:
>> Sounds good. How would you like to do that? >> >> E.g. we could just remove the words "In particular, some GZIP compression >> tools function by partitioning the input, compressing each partition >> separately, and then concatenating the resulting compressed data streams. To >> support this kind of input". We could also remove "In the latter case, the >> number of additional bytes that were read is unspecified." Or something else >> (what would you suggest?) >> >> Thanks. > >> Sounds good. How would you like to do that? >> >> E.g. we could just remove the words "In particular, some GZIP compression >> tools function by partitioning the input, compressing each partition >> separately, and then concatenating the resulting compressed data streams. To >> support this kind of input". We could also remove "In the latter case, the >> number of additional bytes that were read is unspecified." Or something else >> (what would you suggest?) >> >> Thanks. > > Yes, no reason to talk about gzip tools. The focus should be that this > method can read concatenated gzip streams when there is a gzip header > immediately after the gzip trailer, otherwise additional bytes are treated as > End of stream I'm reluctant to make this PR even longer lived. But perhaps this could be made even shorter by dropping the 'self-delimiting' term and its definition? Could something like this work? _In the GZIP file format, compressed data payloads are preceded by a header and followed by a trailer. If a new header immediately follows a trailer, this class continues to decode compressed data as a single, concatenated stream; otherwise, any additional bytes are ignored as if the end of stream is reached._ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1736027146
