[JAVA][NATIVE] Add gzip capability

[inemtsev]

Currently, Java's native HttpClient template does not support gzipped responses from the server. This PR adds this capability and uses the existing flag "useGzipFeature" to guard it

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR solves a reported issue, reference it using GitHub's linking syntax (e.g., having "fixes #123" present in the PR description)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[wing328]

thanks for the pr

please follow step 3 to update the samples so that CI can verify the change.

[wing328]

is it correct to say that this is a breaking change?

[inemtsev]

Technically yes, although I would expect most users to never use this method directly

[wing328]

given that responseInterceptor uses InputStream, we can consider this change a bug fix instead.

[inemtsev]

@martin-mfg @lwlee2608 @welandaz @joschi can you please review?

[inemtsev]

Fixes issue #22326

[wing328]

shouldn't this import for java.util.zip.GZIPInputStream only needed when useGzipFeature is enabled?

[wing328]

i'll fix it with another PR.

thanks for the contribution.

[wing328]

now i see why as there's a function using it without gzip feature enabled.

  public static InputStream getResponseBody(HttpResponse<InputStream> response) throws IOException {
    if (response == null) {
      return null;
    }
    InputStream body = response.body();
    if (body == null) {
      return null;
    }
    Optional<String> encoding = response.headers().firstValue("Content-Encoding");
    if (encoding.isPresent()) {
      for (String token : encoding.get().split(",")) {
        if ("gzip".equalsIgnoreCase(token.trim())) {
          return new GZIPInputStream(body);
        }
      }
    }
    return body;
  }

[inemtsev]

Initially I was also thinking of putting "java.util.zip.GZIPInputStream" behind a guard, but then I thought we should decompress gzip even if we dont request it because some servers respond with gzip compression by default.

[wing328]

thanks for the PR

did a test with the feature enabled and the output compiles without issue

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  6.410 s
[INFO] Finished at: 2025-11-16T18:38:22+08:00
[INFO] ------------------------------------------------------------------------

[wing328]

FYI. Merged #22361 to add new samples (tested in CI)

[inemtsev]

FYI. Merged #22361 to add new samples (tested in CI)

Perfect. Thank you!