Description
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 withtype: object
andadditionalProperties: true
- Specifying the
java
generator with thelibrary: 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 (withlibrary: 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!