Description & Observed Behavior
When generating a Java native client with supportStreaming=true and mapping binary / file types to java.io.InputStream, the generated response handling code contains invalid Java source code.
The generated API method signature correctly uses InputStream as the return type, but the internal implementation still follows the default path—downloading the payload into a temporary file and attempting to return a java.io.File.
This results in the following compilation error:
incompatible types: java.io.File cannot be converted to java.io.InputStream
Affected Configuration:
<supportStreaming>true</supportStreaming>
<typeMappings>
<typeMapping>file=InputStream</typeMapping>
<typeMapping>binary=InputStream</typeMapping>
</typeMappings>
<importMappings>
<importMapping>InputStream=java.io.InputStream</importMapping>
</importMappings>
Expected Behavior
If binary or file is explicitly mapped to InputStream, the generator should:
- Return the HTTP response body directly as an
InputStream without downloading it to a temporary File.
- Generate valid, compilable Java code.
- Preserve the default
File handling behavior if no custom mapping is specified.
Secondary Issue: Raw InputStream request body serialized as JSON
A related problem occurs when sending a raw application/octet-stream request body mapped to InputStream.
Instead of streaming the payload, the generated request builder attempts to serialize the InputStream object via Jackson:
byte[] localVarPostBody = memberVarObjectMapper.writeValueAsBytes(body);
localVarRequestBuilder.method("POST", HttpRequest.BodyPublishers.ofByteArray(localVarPostBody));
This causes the client to send an empty JSON object ({}) instead of the actual binary stream.
Expected Fix for Request Body:
For InputStream / binary inputs, the generator should stream the body directly:
localVarRequestBuilder.method("POST", HttpRequest.BodyPublishers.ofInputStream(() -> body));
Standard application/json payloads should continue to use Jackson serialization.
Reproducer & Workaround
Attached is a minimal reproducer project containing:
- OpenAPI 3.0.3 specification
- Minimal Quarkus server (exposing
POST /binary/echo and POST /binary/upload)
- Generated Java
native client with failing JUnit tests
- A temporary, "quick-and-dirty"
api.mustache template override demonstrating the issue area.
Note: Tested against the latest master branch. No existing open or closed issues matching this behavior were found.
openapi_inputstream_bug.zip
Description & Observed Behavior
When generating a Java
nativeclient withsupportStreaming=trueand mappingbinary/filetypes tojava.io.InputStream, the generated response handling code contains invalid Java source code.The generated API method signature correctly uses
InputStreamas the return type, but the internal implementation still follows the default path—downloading the payload into a temporary file and attempting to return ajava.io.File.This results in the following compilation error:
Affected Configuration:
Expected Behavior
If
binaryorfileis explicitly mapped toInputStream, the generator should:InputStreamwithout downloading it to a temporaryFile.Filehandling behavior if no custom mapping is specified.Secondary Issue: Raw InputStream request body serialized as JSON
A related problem occurs when sending a raw
application/octet-streamrequest body mapped toInputStream.Instead of streaming the payload, the generated request builder attempts to serialize the
InputStreamobject via Jackson:This causes the client to send an empty JSON object (
{}) instead of the actual binary stream.Expected Fix for Request Body:
For
InputStream/ binary inputs, the generator should stream the body directly:Standard
application/jsonpayloads should continue to use Jackson serialization.Reproducer & Workaround
Attached is a minimal reproducer project containing:
POST /binary/echoandPOST /binary/upload)nativeclient with failing JUnit testsapi.mustachetemplate override demonstrating the issue area.Note: Tested against the latest
masterbranch. No existing open or closed issues matching this behavior were found.openapi_inputstream_bug.zip