Skip to content

fix(java): map OpenAPI 3.1 null type to Object to prevent ModelNull generation #23961

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.

Sign up for GitHub

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

Closed
anupamchaubey wants to merge 2 commits into from
Closed

fix(java): map OpenAPI 3.1 null type to Object to prevent ModelNull generation #23961

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c4c5c82
fix(java): map OpenAPI 3.1 null type to Object to prevent ModelNull g…
anupamchaubey Jun 6, 2026
ffac7aa
refactor(java): refine null-type handling and preserve fail-fast beha…
anupamchaubey Aug 9, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 23 additions & 4 deletions ...enapi-generator/src/main/java/org/openapitools/codegen/languages/AbstractJavaCodegen.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -303,6 +303,7 @@ public AbstractJavaCodegen() {
typeMapping.put("date", "Date");
typeMapping.put("file", "File");
typeMapping.put("AnyType", "Object");
typeMapping.put("null", "Object");

@Mattias-Sehlstedt Mattias-Sehlstedt Jul 31, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this serve any purpose? Isn't the idea that null should always be handled before any typeMapping?


importMapping.put("BigDecimal", "java.math.BigDecimal");
importMapping.put("UUID", "java.util.UUID");
Expand Down Expand Up @@ -1093,6 +1094,11 @@ public String toModelFilename(String name) {

@Override
public String getTypeDeclaration(Schema p) {
// Intercept "null" explicitly to prevent complex object resolution
if (p != null && "null".equalsIgnoreCase(p.getType())) {
return "Object";
}

Schema<?> schema = unaliasSchema(p);
Schema<?> target = ModelUtils.isGenerateAliasAsModel() ? p : schema;
if (ModelUtils.isArraySchema(target)) {
Expand Down Expand Up @@ -1866,16 +1872,29 @@ public String toExampleValue(Schema p) {

@Override
public String getSchemaType(Schema p) {
if (p == null) {

@Mattias-Sehlstedt Mattias-Sehlstedt Jul 31, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this fallback necessary for the fix? To me it seems like a rather large change in behavior, and I fail to see why we would want to have a fallback with an error rather than a complete ceasing of processing? Surely something is very wrong if we get here (and this isn't the proper way to handle that)?

LOGGER.error("Schema is null");
return "Object";
}

// 1. First, call the parent method to extract the schema type string
String openAPIType = super.getSchemaType(p);

// don't apply renaming on types from the typeMapping
if (null == openAPIType) {
LOGGER.error("No Type defined for Schema {}", p);

@Mattias-Sehlstedt Mattias-Sehlstedt Jul 31, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we really log an error if this is an expected processing branch now?

return "Object"; // Safe fallback to prevent NullPointerException later
}

// 2. Intercept the "null" type string immediately before it routes to typeMapping or toModelName
if ("null".equalsIgnoreCase(openAPIType) || "null".equalsIgnoreCase(p.getType())) {

@Mattias-Sehlstedt Mattias-Sehlstedt Jul 31, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we sure that we should never check OAS 3.1 types here? Or is it expected that the openAPIType or normalization has handled that (but if so, why even check getType)?

return "Object";
}

// 3. Don't apply renaming on types from the typeMapping
if (typeMapping.containsKey(openAPIType)) {
return typeMapping.get(openAPIType);
}

if (null == openAPIType) {
LOGGER.error("No Type defined for Schema {}", p);
}
return toModelName(openAPIType);
}

Expand Down
9 changes: 9 additions & 0 deletions .../openapi-generator/src/test/java/org/openapitools/codegen/java/JavaClientCodegenTest.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4556,6 +4556,15 @@ public void testSwagger2TagImportRestAssured() throws IOException {
assertThat(content)
.contains("import io.swagger.v3.oas.annotations.tags.*;")
.contains("@Tag(");

}

@Test
public void testNullTypeMapsToObject() {
final JavaClientCodegen codegen = new JavaClientCodegen();
Schema nullSchema = new Schema().type("null");
Assert.assertEquals(codegen.getSchemaType(nullSchema), "Object");
Assert.assertEquals(codegen.getTypeDeclaration(nullSchema), "Object");
}

}
Loading