Openapi-generator: [java] Combining "properties" and "additionalProperties" in one class generates broken Jackson mapping.

[r-alukhanov]

Description

If using both "properties" and "additionalProperties", the generated class extends HashMap and contains plain properties. Like this:

public class Example extends HashMap<...>  {
  @JsonProperty("a")
  private String a;
  ...
}

Such a class cannot be meaningfully deserialised using Jackson. Jackson puts all the fields as key/value pairs into the HashMap ignoring the plain fields. In provided example getA() would return "null", while get("a") contains the value.

openapi-generator version

Used version: openapi-generator-maven-plugin : 3.3.3

OpenAPI declaration file

Example:
  type: object
  properties:
    a:
    type: string
  additionalProperties: true

Suggest a fix/enhancement

I would suggest to generate such a class (which has both "properties" and "additionalProperites") as:

public class Example {
  private String a;
  private HashMap<> otherProperties;
  ...
}

Similar suggestion in "swagger-codegen" project:
https://github.com/swagger-api/swagger-codegen/issues/5187

[claudemamo]

Any updates on this?

[vandeseer]

We are facing the very same issue using openapi-generator-gradle-plugin : 4.0.1 and the jaxrs-jersey generator.

Are there any workarounds beside not using both (i.e. properties and additionalProperties) at the same time? Are there any plans to fix it?

Thanks!

[FatCash]

Also having problems with serialize/deserialize properly because of this.
Desired approach would be to populate a mustache flag like {{hasAdditionalProperties}} on class level (not vars level), similar to {{isMapContainer}} which is currently true if additionalProperties: true
Then we could use it however we want in mustache to add the otherProperties field and necessary json annotations and builders etc..

The automatic extends HashMap<...> should not be there, instead users can add that themselves in mustasche by checking the {{hasAdditionalProperties}} flag.

[wakedeer]

Any updates on this issue?

[harel-e]

I think that having a member of HashMap instead of extending HashMap would address the issue.
@JsonAnyGetter and @JsonAnySetter are designed for this exactly.
Like @FatCash suggested, there could be a feature flag that would allow backward compatibility (though it seems broken right now anyway)