Skip to content

[java][microprofile] Don't emit JsonNullable helper calls that are never defined - #9

Closed
Ignacio-Vidal wants to merge 13 commits into
masterfrom
fix-microprofile-jsonnullable-helpers
Closed

[java][microprofile] Don't emit JsonNullable helper calls that are never defined#9
Ignacio-Vidal wants to merge 13 commits into
masterfrom
fix-microprofile-jsonnullable-helpers

Conversation

@Ignacio-Vidal

Copy link
Copy Markdown
Owner

The microprofile client does not support the Jackson Nullable library — the
generator documents this itself:

openApiNullable — Enable OpenAPI Jackson Nullable library. Not supported by microprofile library.

So a property carrying x-is-jackson-optional-nullable is still rendered as a
plain field. But equals/hashCode emitted equalsNullable(...) /
hashCodeNullable(...) for it anyway, while the helper definitions are gated
on a different, model-level extension (x-jackson-optional-nullable-helpers)
that core only sets from the schema's own nullability. When the two disagree the
generated model does not compile:

error: cannot find symbol
  symbol:   method equalsNullable(String,String)
  location: class CatResponseV2

When this happens

The two extensions diverge whenever a spec author writes
x-is-jackson-optional-nullable by hand — which is the only way to request a
JsonNullable property from the jaxrs-spec generator, since
AbstractJavaCodegen.isAddNullableImports() is called solely by
JavaClientCodegen and SpringCodegen.

Vendor extensions live in the spec, so they apply to every generator task
reading it. A spec shared between a jaxrs-spec server and a microprofile client
carries the extension into both, and the client stops compiling.

Reproduced on a minimal spec with all three nullability spellings (3.1 type
union, union + extension, nullable: true + extension): the microprofile field
is a plain String in every case, so openApiNullable cannot rescue it.

Fix

Gate the call sites in microprofile/pojoOverrides.mustache on the same
model-level extension as the definitions, so they can no longer disagree,
falling back to Objects.equals / the bare field name.

This only changes output that previously failed to compile — regenerating all
14 microprofile sample configs produces zero diff.

Tests

New testMicroprofileIgnoresJacksonOptionalNullableExtension_issue24560, which
fails on master and passes with the fix. JavaClientCodegenTest 266 green.

zhornback and others added 13 commits July 31, 2026 11:28
…ols#22494) (OpenAPITools#23398)

* [python-fastapi] Default default value ... instead of None (OpenAPITools#22494)

With various FastAPI parameters (Query, Path, Header, Cookie, Body,
Form, and File) the default value of None is a valid value, but
signifies that the parameter is optional.  To allow for required
parameters, default should either not be set at all or be set to '...'
(ellipsis).

Issue: OpenAPITools#22494

* Update samples after previous changes

* Add generated newlines

* Adjust test to expect ...

Since the initial PR, a new test was added expecting None rather than
'...'.  Changing test and samples as needed.

* Update test and samples after last change

A new test needed to be adjusted, the Form was required so ... is more
appropriate than None.
…4534)

Bumps [docker/login-action](https://github.com/docker/login-action) from 4 to 4.5.2.
- [Release notes](https://github.com/docker/login-action/releases)
- [Commits](docker/login-action@v4...v4.5.2)

---
updated-dependencies:
- dependency-name: docker/login-action
  dependency-version: 4.5.2
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [sbt/setup-sbt](https://github.com/sbt/setup-sbt) from 1 to 1.5.4.
- [Release notes](https://github.com/sbt/setup-sbt/releases)
- [Commits](sbt/setup-sbt@v1...v1.5.4)

---
updated-dependencies:
- dependency-name: sbt/setup-sbt
  dependency-version: 1.5.4
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…ols#24536)

A server presenting a certificate issued by a private CA is unreachable by
a generated client: the default trust store holds public authorities only,
and Configuration exposed no way to say otherwise. The escape hatch it does
offer, `Configuration#use`, cannot help — Faraday settles TLS when it builds
the connection, before any middleware runs.

`ssl` is handed to Faraday verbatim, so anything the adapter understands
works, `{ ca_file: ... }` and `{ verify: false }` alike. It defaults to an
empty hash, which is what Faraday assumes when the option is absent, so
generated clients are unchanged unless they set it.

- configuration.mustache: add the :ssl accessor, initialized to {}
- connection.mustache: pass it to Faraday.new as a connection option
- README.mustache: document it in the configuration example
- Regenerate the petstore and qdrant samples

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ttributes (OpenAPITools#24533)

* ✨ Added required and dataType properties to validationAttributes.mustache in typescript-fetch generator

* Updated samples

* Fix HTML escaping
* fix(dart-dio): PATCH tri-state optional handling

* fix(dart-dio): avoid whitespace-only sample churn in class template

* fix(dart-dio): remove trailing ? from Optional-wrapped fields

The outer Optional should never be null—only the inner value can be null.
Field type should be Optional<T?>, not Optional<T?>?

This fixes compilation errors when serializer tries to access .isPresent
on a potentially null Optional.

* fix: more testings which ended up actually needing the deserialization part

---------

Co-authored-by: Jeffrey Oloresisimo <jeffrey.oloresisimo@tmasystems.com>
…avalin templates (OpenAPITools#24556)

* [kotlin] Add = null default for optional parameters in jvm-ktor and javalin templates

Fixes OpenAPITools#23100

Several Kotlin templates made optional parameters nullable (Type?) but
did not assign = null as a default value, forcing callers to explicitly
pass null for every optional parameter instead of omitting them.

Updated templates:
- kotlin-client/libraries/jvm-ktor/api.mustache
- kotlin-server/libraries/javalin5/service.mustache
- kotlin-server/libraries/javalin5/serviceImpl.mustache
- kotlin-server/libraries/javalin6/service.mustache
- kotlin-server/libraries/javalin6/serviceImpl.mustache

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* [kotlin] Add `= null` default for optional parameters in jvm-ktor templates and javalin serviceImpls

Expanded test coverage for jvm-ktor optional parameters to verify `= null` defaults in generated code. Updated javalin5 and javalin6 serviceImpl templates to include correct default value assignments.

* [kotlin] Fix nullable Flow types in javalin5 and javalin6 service templates

* Update samples for kotlin jvm-ktor and javalin templates

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* [kotlin] Simplify default value template logic per PR review

Move defaultValue outside required-check since it always applies,
simplify nullable/default patterns in jvm-ktor api.mustache and
javalin5/javalin6 service.mustache templates.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* [kotlin] Add default `= null` for optional parameter in `addPet` method

* disabled failing tests

---------

Co-authored-by: Bartłomiej Kozak <b.kozak@avsystem.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: Bartłomiej Kozak <bartlomiejkozak@proton.me>
* normalize 3.1 spec map schema

* update samples

* return updated map schema

* refactor nullable check

* Update modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java

Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>

---------

Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
…ver defined

The microprofile client does not support the Jackson Nullable library, so a
property carrying `x-is-jackson-optional-nullable` is still rendered as a plain
field. equals/hashCode nevertheless emitted `equalsNullable(...)` /
`hashCodeNullable(...)` for it, while the helper *definitions* are gated on a
different, model-level extension (`x-jackson-optional-nullable-helpers`) that
core only sets from the schema's own nullability. When the two disagree the
generated model does not compile:

    error: cannot find symbol
      symbol: method equalsNullable(String,String)

The two extensions diverge whenever a spec author writes
`x-is-jackson-optional-nullable` by hand, which is the only way to request a
JsonNullable property from the jaxrs-spec generator. Vendor extensions are
spec-level, so a spec shared between a jaxrs-spec server and a microprofile
client carries the extension into both.

Gate the call sites on the same model-level extension as the definitions, so
they can no longer disagree, falling back to `Objects.equals` / the bare field.
This only changes output that previously failed to compile: regenerating every
microprofile sample produces no diff.
@Ignacio-Vidal

Copy link
Copy Markdown
Owner Author

Opened upstream as OpenAPITools#24560.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants