RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater [v3]

Eirik Bjørsnøs eirbjo at openjdk.org
Fri Jan 24 20:59:51 UTC 2025


On Thu, 2 Jan 2025 18:26:16 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The class `GZIPOutputStream` extends `DeflaterOutputStream`, which is logical because the GZIP encoding is based on ZLIB "deflate" encoding.
>> 
>> However, while `DeflaterOutputStream` provides constructors that take a custom `Deflater` argument supplied by the caller, `GZIPOutputStream` has no such constructors.
>> 
>> As a result, it's not possible to do entirely reasonable customization, such as configuring a `GZIPOutputStream` for a non-default compression level.
>> 
>> This change adds a new `GZIPOutputStream` constructor that accepts a custom `Deflater`, and also adds a basic unit test for it and all of the other `GZIPOutputStream` constructors, based on the existing test `BasicGZIPInputStreamTest.java` which does the same thing for `GZIPInputStream`.
>
> Archie Cobbs 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 six additional commits since the last revision:
> 
>  - Bump copyright year to 2025.
>  - Merge branch 'master' into JDK-4452735
>  - Address review comments.
>  - Merge branch 'master' into JDK-4452735
>  - Merge branch 'master' into JDK-4452735
>  - Add a GZIPOutputStream() constructor that takes a Deflator.

A tangential concern when allowing a custom deflater / inflater is to document the resposibility for resource management.

With https://bugs.openjdk.org/browse/JDK-8225763 making Inflater/Deflater implement AutoCloseable perhaps some documentation / snippet examples could be added to document best practise for making sure a custom Deflater does not leak.

See https://bugs.openjdk.org/browse/JDK-8066583 for an existing issue for DeflaterOutputStream, but I guess this is relevant for any API consuming custom Inflater/Deflaters.

Maybe not for this PR to implement, but worth thinking through while considering this change I think.

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

PR Comment: https://git.openjdk.org/jdk/pull/20226#issuecomment-2613366756


More information about the core-libs-dev mailing list