Bug Report Checklist
Description
When useOneOfInterfaces=true is set and a oneOf schema consists of array variants (e.g. List<VariantA> | List<VariantB>), the generator produces an empty, unusable Java interface:
public interface MyRequest {
}
This interface is useless because Java's List<T> cannot implement a user-defined interface retroactively. The API method parameter has type MyRequest, but there is no valid value that can be passed ? the generated code cannot be used at all.
Without useOneOfInterfaces, the generator correctly produces a working wrapper class:
public class MyRequest extends AbstractOpenApiSchema { ... }
This wrapper holds either a List<VariantA> or List<VariantB> and includes proper Gson serialization/deserialization logic.
The interface approach only makes sense for object-type oneOf variants, where the concrete classes can implement the generated interface:
public class VariantA implements MyRequest { ... }
public class VariantB implements MyRequest { ... }
openapi-generator version
7.x (confirmed on latest master)
OpenAPI declaration file content or url
components:
schemas:
MyRequest:
oneOf:
- type: array
items:
$ref: '#/components/schemas/VariantA'
- type: array
items:
$ref: '#/components/schemas/VariantB'
VariantA:
type: object
properties:
fieldA:
type: string
VariantB:
type: object
properties:
fieldB:
type: integer
Generation Details
openapi-generator generate \
-i spec.yaml \
-g java \
--library okhttp-gson \
--additional-properties useOneOfInterfaces=true
Steps to reproduce
- Use the spec above with
useOneOfInterfaces=true and any Java library.
- Inspect the generated
MyRequest.java ? it is an empty interface.
- Try to call the generated API method ? no valid argument can be constructed.
Suggest a fix
When generating a oneOf interface model, check whether all variants are array types. If so, skip interface generation and fall back to the existing AbstractOpenApiSchema wrapper class, which already handles this case correctly.
The check can be added in DefaultCodegen.addOneOfInterfaceModel() or in preprocessOpenAPI() where oneOf schemas are scanned: if every entry in cm.oneOf resolves to an array schema, do not add the model to addOneOfInterfaces and do not add it to oneOfInterfaceNames.
Bug Report Checklist
Description
When
useOneOfInterfaces=trueis set and aoneOfschema consists of array variants (e.g.List<VariantA> | List<VariantB>), the generator produces an empty, unusable Java interface:This interface is useless because Java's
List<T>cannot implement a user-defined interface retroactively. The API method parameter has typeMyRequest, but there is no valid value that can be passed ? the generated code cannot be used at all.Without
useOneOfInterfaces, the generator correctly produces a working wrapper class:This wrapper holds either a
List<VariantA>orList<VariantB>and includes proper Gson serialization/deserialization logic.The interface approach only makes sense for object-type
oneOfvariants, where the concrete classes can implement the generated interface:openapi-generator version
7.x (confirmed on latest master)
OpenAPI declaration file content or url
Generation Details
Steps to reproduce
useOneOfInterfaces=trueand any Java library.MyRequest.java? it is an empty interface.Suggest a fix
When generating a
oneOfinterface model, check whether all variants are array types. If so, skip interface generation and fall back to the existingAbstractOpenApiSchemawrapper class, which already handles this case correctly.The check can be added in
DefaultCodegen.addOneOfInterfaceModel()or inpreprocessOpenAPI()whereoneOfschemas are scanned: if every entry incm.oneOfresolves to an array schema, do not add the model toaddOneOfInterfacesand do not add it tooneOfInterfaceNames.