Skip to content

[BUG] [Java] POJO with "library: native" with "additionalProperties:true" property leads to wrong generation #20747

Open
@narcoticfresh

Description

@narcoticfresh

First of all, I'd like to salute all people that help this project - it is really quite an undertaking! Thanks so much!

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

It seems that the combination of

  • Having a 3.1.0 spec
  • Having an object with additionalProperties: false that has a property with type: object and additionalProperties: true
  • Specifying the java generator with the library: native spec

Leads to a de-facto incorrect POJO that has extends HashMap<String, Object> when in fact that only applies to the child property, not the containing POJO.

openapi-generator version

The behavior did not happen in generator 7.6.0, it starts to happen in 7.7.0 and still happens to 7.11.0 and current latest in docker registry (tested as of "now"; 2025-02-27T09:39:00+0100).

OpenAPI declaration file content or url

Conside this very isolated openapi.yaml

openapi: 3.1.0
info:
  title: "TEST"
  version: 1.0.0
components:
  schemas:
    SampleObject:
      type: object
      properties:
        id:
          type: string
          title: ID
          description: 'Unique identifier'
        subObject:
          type: object
          description: 'An child property object allowing all fields.'
          title: Subobject
          additionalProperties: true # note the true here!
      additionalProperties: false # note the false here!

Note that SampleObject has additionalProperties: false, but the property subObject has additionalProperties: true.

I use the following YAML spec:

generatorName: java
outputDir: ./java-test
inputSpec: openapi.yaml
library: native

And this results in this POJO class definition (refer to the full generated source here if needed):

public class SampleObject extends HashMap<String, Object> {
 // removed for relevance

  public SampleObject() { 
  }

  // removed for relevance
  public SampleObject subObject(@javax.annotation.Nullable Map<String, Object> subObject) {
    this.subObject = subObject;
    return this;
  }

So even though SampleObject has additionalProperties: false, it extends HashMap, which breaks our client expectations and our API we need to generate.

Sidenote

Interestingly, when not specifying a library, the class is generated as expected.

If we use this YAML spec (note the absence of library:

generatorName: java
outputDir: ./java-test
inputSpec: openapi.yaml

We get this class definition - which is correct (again, click here for the full generated class code):

public class SampleObject {
  // removed for relevance
  public SampleObject() { 
  }

  // removed for relevance
  public SampleObject subObject(@javax.annotation.Nullable Map<String, Object> subObject) {
    this.subObject = subObject;
    return this;
  }
Generation Details

All details are specified above; i used docker cli, version 7.12.0-SNAPSHOT as of now and used the simple cli command

generate --config spec.yaml 

with the spec

generatorName: java
outputDir: ./java-test
inputSpec: openapi.yaml
library: native
Steps to reproduce
  • Create the openapi.yaml as specified above
  • Execute the generate command with the spec as specified above (with library: native); with version >7.6.0
  • Note that it is different without the library setting
  • Observe the behavior as described
Related issues/PRs

Couldn't find anything for this

Suggest a fix

I really think this is a bug - why would native implementation need the POJO to extend HashMap? This oppens the possibility to add any properties that are actually not used when sending the content to the receiving backend and/or can lead to backend error responses in our case (as additonalProperties is false) and of course we validate as such.

Thanks so much!

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions