[BUG] Java / Native Client does not respect ContentType (body always -> ObjectMapper)

[PF-Magic]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

Content-Type in request response is not respected in generated Java Native client.
Generated Java Native client is mapping all response body into ObjectMapper causing databind Exceptions.
See api.mustache line 278

localVarResponse.body() == null ? null : memberVarObjectMapper.readValue(localVarResponse.body(), new TypeReference<{{{returnType}}}>() {}) // closes the InputStream

openapi-generator version

found in openapi-generator-7.6.0.jar, retestet with current master.

OpenAPI declaration file content or url

openapi: "3.0.3"
info:
  title: Example
  version: 1.0.0
servers: 
  - url: "http://localhost:3000"
paths: 
 "/example":
    get: 
      responses:
        '200':
          description: example response
          content:
            text/csv:
              schema:
                type: string
components:
  schemas:
    Example:
      title: Example
      description: Example
      type: object
      properties:
        name:
          type: string
          pattern: '^[a-zA-Z0-9]+[a-zA-Z0-9\.\-_]*[a-zA-Z0-9]+$'

Generation Details

java -jar openapi-generator-cli.jar \
    generate \
    -i /tmp/example.yaml \
    -g java --library native \
    --additional-properties packageName=example \
    -o /tmp/example

Steps to reproduce

Having YAML with Response other than application/json

      responses:
        '200':
          description: OK
          content:
            text/csv:
              schema:
                type: string

generate NATIVE (-g java --library native) Java client with with CLI Generator.

Produced Api Class operation snipped (exampleGetWithHttpInfo())

[CUT]
      try {
        if (localVarResponse.statusCode()/ 100 != 2) {
          throw getApiException("exampleGet", localVarResponse);
        }
        return new ApiResponse<String>(
          localVarResponse.statusCode(),
          localVarResponse.headers().map(),
          localVarResponse.body() == null ? null : memberVarObjectMapper.readValue(localVarResponse.body(), new TypeReference<String>() {}) // closes the InputStream
        );
      } finally {
      }
[CUT]

In generated code (DefaultApi.java) there is not Content-Type specific response mapping. The current code assumes all responses are application/json and processing by ObjectMapper causing exceptions.

In Jersey2 and Jersey3 it is handled correctly.

Call exampleGetWithHttpInfo() on an endpoint providing some string and content-type other than application/json.

Related issues/PRs

Not known.

Suggest a fix

Jersey2 and Jersey3 has correct Content-Type handling.
Just implement the deserialise as in Jersey3:

https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources/Java/libraries/jersey3/ApiClient.mustache

  /**
   * Deserialize response body to Java object according to the Content-Type.
   *
   * @param <T> Type
   * @param response Response
   * @param returnType Return type
   * @return Deserialize object
   * @throws ApiException API exception
   */
  @SuppressWarnings("unchecked")
  public <T> T deserialize(Response response, GenericType<T> returnType) throws ApiException {
    if (response == null || returnType == null) {
      return null;
    }

    if ("byte[]".equals(returnType.toString())) {
      // Handle binary response (byte array).
      return (T) response.readEntity(byte[].class);
    } else if (returnType.getRawType() == File.class) {
      // Handle file downloading.
      T file = (T) downloadFileFromResponse(response);
      return file;
    }

    // read the entity stream multiple times
    response.bufferEntity();

    return response.readEntity(returnType);
  }

If needed I can contribute by fixing this bug (adopt mustache templates / create patch)