fix(java): fix oneOf interface ignoring useJakartaEe for @Generated a…

[anupamchaubey]

Fixes an issue where the generated oneOf interface in Java generators ignores the useJakartaEe=true configuration and hardcodes javax.annotation.Generated instead of using the dynamic javaxPackage.

Root cause: The synthetic oneOf interface model map created in DefaultCodegen.java was missing the javaxPackage context property.

Fix: Injected javaxPackage into the oneOf model map entries (objsValue.put("javaxPackage", ...)) so templates properly receive jakarta when useJakartaEe=true is enabled.

Fixes #24889

PR checklist

• Read the contribution guidelines.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.
  /cc @wing328 @cbornet @jmini

---

Summary by cubic

Fixes the Java generator ignoring useJakartaEe=true for the oneOf interface's @Generated annotation. It previously hardcoded javax.annotation.Generated; now it follows the configured javaxPackage and emits jakarta.annotation.Generated when enabled. Fixes #24889.

^{Written for commit f004b7f. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java">

<violation number="1" location="modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java:606">
P2: This line is redundant: `objsValue.putAll(additionalProperties)` two lines above already copies `javaxPackage` into `objsValue` for Java generators, because `applyJavaxPackage()`/`applyJakartaPackage()` write it into `additionalProperties` during `processOpts()`, before `postProcessAllModels()` runs. The new `put` overwrites the same key with the same value, so it cannot change the template context for Java. If the oneOf interface was still rendering `javax`, this line does not fix it — the real cause is likely how the oneOf template consumes the model map entries, not a missing context property. Verify the actual rendering path or remove this no-op.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: This line is redundant: objsValue.putAll(additionalProperties) two lines above already copies javaxPackage into objsValue for Java generators, because applyJavaxPackage()/applyJakartaPackage() write it into additionalProperties during processOpts(), before postProcessAllModels() runs. The new put overwrites the same key with the same value, so it cannot change the template context for Java. If the oneOf interface was still rendering javax, this line does not fix it — the real cause is likely how the oneOf template consumes the model map entries, not a missing context property. Verify the actual rendering path or remove this no-op.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java, line 606:

<comment>This line is redundant: `objsValue.putAll(additionalProperties)` two lines above already copies `javaxPackage` into `objsValue` for Java generators, because `applyJavaxPackage()`/`applyJakartaPackage()` write it into `additionalProperties` during `processOpts()`, before `postProcessAllModels()` runs. The new `put` overwrites the same key with the same value, so it cannot change the template context for Java. If the oneOf interface was still rendering `javax`, this line does not fix it — the real cause is likely how the oneOf template consumes the model map entries, not a missing context property. Verify the actual rendering path or remove this no-op.</comment>

<file context>
@@ -603,6 +603,7 @@ public Map<String, ModelsMap> postProcessAllModels(Map<String, ModelsMap> objs)
                 objsValue.put("classname", cm.classname);
                 objsValue.putAll(additionalProperties);
                 objs.put(cm.name, objsValue);
+                objsValue.put("javaxPackage", additionalProperties.getOrDefault("javaxPackage", "javax"));
             }
 
</file context>

[wing328]

i don't think default codegen should store java specified values (e.g. javaxPackage).

can this be fix in java abstract code gen instead?

[Mattias-Sehlstedt]

The root cause identified is not correct. The reported issue stemmed from the fact that microprofile itself controlled jakarta with microprofileRestClientVersion, and basically override useJakartaEe. The fix would if anything be to clarify that this is the case for useJakartaEe in the docs (possibly by entirely removing useJakartaEe from microprofile documentation).