RFR: 4890732: GZIPOutputStream doesn't support optional GZIP fields [v6]

[Lin Zang]

On Thu, 15 Apr 2021 12:41:17 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 4890732: GZIPOutputStream doesn't support optional GZIP fields
>
> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into gzip-field
>  - remove trailing spaces
>  - Use record and Builder pattern
>  - add class GZIPHeaderData, refine testcases
>  - update copyright
>  - reuse arguments constructor for non-argument one.
>  - add test case
>  - remove trailing spaces
>  - 4890732: support optional GZIP fields in GZIPOutputStream

Dear Lance, 
    Sorry for late response.
    
>  the updates to the PR does not include any proposed changes to GZIPInputStream and this should be something we should come to an agreement on as it can possibly impact the direction. I am not sure we need to add multiple constructors to GZIPOutputStream as part of the proposed change.

With the latest change, the gzip header data could be composed by GZIPHeaderBuilder, But it seems ithere still need a way to write the header data when GZipOutputStream is created.Therefore IMHO at least one more constructor is required which could accept the header data and then write them.

For GZIPInputStream, as there is GZIPHeaderBuilder now, I think there is no need to add any constructor for it. We can use the builder to generate gzip header data when parsing the Gzip header.  For example, re-write the readHeader() to generate gzip header data, and provide api that user could access the header data.

> It would also be useful to know where is the actual pain point, that is, is there a tool or API not having these fields settable for that is causing an issue? I ask so that we can make sure that we are taking that into consideration.

Frankly, I only experienced the use of extra gzip header field when work on the gziped heap dump file generated by  `jmap -dump` with `gz` option. It uses the extra field to provide some meta info that maybe used for decompressing.  I didn't see the usage of these header info in other place.  So I believe that not having these fields settable is OK  at present (at least).

The intention that I try to provide this PR is that I think, since the gzip file spec has described the header field, maybe in some scenario user may need a way to access/set it in Java.  

Thanks.
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/3072