Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
5 of 6 tasks
narcoticfresh opened this issue Feb 27, 2025 · 0 comments

Comments

@narcoticfresh
Copy link

narcoticfresh commented Feb 27, 2025

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant