For openapi yaml files that contain anyOf or oneOf or allOf, it would generate java model class with no fields, but just equals or toString. Once they are removed, java model would be generated with fields.
hello @Jovons can you please share an example of wrong output?
Hi have the same issue (swagger-codegen v3.0.11).
OpenApi part of component:

Generated model:

Thanks for a response.
Gabriele
Tested in context of : "library" set to "okhttp-gson".
There is even seen generated empty interface or placing parent class two wrong place like to position where should be just interface interface or as ", ," (so missing).
So in case of multi-parent and java it should leads to:
Hi can you please share a spec exposing the issue? and also please test with last version of codegen thanks
Tested with 3.0.14 (current stable) and jersey2 library. Get the same result as @gdarrigo.
Spec file:
openapi3.zip
@gdarrigo your StatoTessera schema is not valid because an instance cannot be type: object and type: string at the same time.
hello @Jovons @gdarrigo @gdarrigo
please, keep in mind that for sample:
variable-value:
anyOf:
- type: boolean
- type: integer
- type: number
- type: string
- type: array
items:
anyOf:
- type: boolean
- type: integer
- type: number
- type: string
we're saying that for java language Variable-value, can be a boolean, a integer, a number, a string or an array. this is not defined as an object
@gracekarina @HugoMario is there any progress on this issue?
@HugoMario Hi Hugo, Java could not express oneOf or anyOf indeed, so it's pojo's consumer's job to check only one of the fields is not null. Now swagger-codegen generates a pojo with no fields, this is not right. It could generates a pojo with all oneOf/anyOf fields, and then a validator or at least an annotation that says the pojo has these special fields. :))
@Jovons,
I agree with you about empty pojo is wrong. However you see the anyOf as a list of fields, but that's not the accuracy concept. anyOf is a list of schemas (objects for java generator). It does not make sense to have a pojo with a list of fields based on this design when you can use the proper design for that.
Most helpful comment
Tested with 3.0.14 (current stable) and jersey2 library. Get the same result as @gdarrigo.
Spec file:
openapi3.zip