-
Notifications
You must be signed in to change notification settings - Fork 175
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
About the problem that property names in Jackson
and definitions in Kotlin
are sometimes different.
#630
Labels
Comments
This was referenced Feb 19, 2023
k163377
changed the title
Add an option to use only names on
The problem that the serialization result differs from the definition on Mar 3, 2023
Kotlin
.Kotlin
and the addition of a new option.
k163377
changed the title
The problem that the serialization result differs from the definition on
About the problem that property names in Mar 3, 2023
Kotlin
and the addition of a new option.Jackson
and definitions in Kotlin
are sometimes different.
This was referenced Mar 3, 2023
k163377
added a commit
to k163377/jackson-module-kotlin
that referenced
this issue
Jul 15, 2023
k163377
added a commit
to k163377/jackson-module-kotlin
that referenced
this issue
Jul 15, 2023
This feature will be available in |
raymank26
added a commit
to FameFlow/openapi-javalin-generator
that referenced
this issue
Mar 14, 2024
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
About current problems
Currently, in
jackson-module-kotlin
, property names onJackson
(e.g., property names in serialization results) may differ from their definitions inKotlin
.Also, annotations on parameters do not work in this situation(#603).
Below is a summary of the situations in which this problem occur.
When the result of converting the name of a getter does not match the property name
This problem is especially likely to occur when the string converted from the generated getter name according to the
Java Beans
specification is at variance with the property name onKotlin
.This is the case if the property name starts with an uppercase letter (#173), or if use a property name that starts with a single lowercase letter (#570), etc.
If the property visibility is
internal
In this case, it is due to the fact that the name of the generated getter is given a suffix generated by
Kotlin
(see #71).If the property name contains
-
.Field names containing hyphens are truncated when serialized(#434).
This is a side effect of removing the random suffix given to the name of the getter generated for the
value class
(see #383).Regarding workarounds that users can do.
Basically, it is recommended to use
JsonProperty
.As mentioned above, annotations on parameters do not work in this case, so they must be added to getter or field.
There are other ways to use annotations such as
JvmField
orJvmName
.Proposed modification of
jackson-module-kotlin
.It is counter-intuitive behavior that the definition on
Kotlin
and the serialization result are different.Therefore, we are considering adding an option to use the name on
Kotlin
in preference to the getter name during serialization.If this option is enabled, it changes the processing of
KNAI.findImplicitPropertyName
.Additional context
Example implementation of this option:
#451
Enabling this option increases reflection processing and will probably decrease processing speed.
Also, if this option is enabled, several behaviors are changed destructively.
For example, getter name changes with
JvmName
will be disabled, and annotations that previously did not work during serialization will work.Therefore, this option cannot be enabled by default for the time being.
Amendment: behavior of
is-getter
A fix for the
is-getter
problem as reported in #340 will be released in 2.15.The text was updated successfully, but these errors were encountered: